Re: pgbench - test whether a variable exists

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: pgbench - test whether a variable exists
Дата
Msg-id alpine.DEB.2.21.2004130859520.27777@pseudo
обсуждение исходный текст
Ответ на Re: pgbench - test whether a variable exists  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pgbench - test whether a variable exists
Re: pgbench - test whether a variable exists
Список pgsql-hackers
Bonjour Michaël,

>> Patch v3 is also a rebase.
>
> This has rotten for half a year, so I am marking it as returned with
> feedback.  There have been comments from Alvaro and Andres as well...

Attached a v4. I'm resurrecting this small patch, after "\aset" has been 
added to pgbench (9d8ef988).

Alvaro's feedback was about the lack of "pg_strndup" availability, but he 
concluded that it would seldom be used if available, so it was not worth 
the effort to add it for the sake of this small patch.

About arguments for this patch:

First, this syntax is already available in "psql", and I think that 
keeping pgbench/psql in sync is better for users' ease of mind. That is 
the initial (weak) argument about which Andres objected.

Second, it is on the path to move pgbench expression as a front-end util 
that can be used by psql, which is still a project of mine, although I 
have not started much on that yet. For that pgbench expressions must be 
able to do what psql can do before merging, including this test. Other 
things needed before this is stated are a working free on expression trees 
(trivial), merging variable management to some extent (at least the same 
API, possibly the same implementation would save quite a few lines of 
code), having string values, support for :'var' and :"var" string escapes… 
no very big deals, but some work anyway.

Third, I have a practical pgbench-specific use case, which motivates the 
resurrection right now: I'd like to be able to run a benchmark with a mix 
of SELECT, UPDATE, DELETE and INSERT commands, that is expected in a 
normal functioning database system.

For INSERT, I think I have a few ideas for possible and simple solutions, 
but it still need some thoughts so this is for later. The key issue is 
how to handle a varying number of rows.

Under DELETE, some SELECT and UPDATE scripts may fail because the data are 
not there anymore, hence the ability to check whether a variable is empty 
comes handy:

Low probability delete script:

   \set uid random(...)
   DELETE FROM Operations WHERE oid IN (... :uid) \;
   DELETE FROM Accounts WHERE aid IN (... :uid) \;
   DELETE FROM Client WHERE ... :uid;

Parallel running update script:

   -- a pseudo random client arrives
   \set uname random(...)
   SELECT uid FROM Client WHERE uname = :uname::TEXT \aset
   -- remainder must be skipped if no client was found
   \if :{?uid}
     SELECT SUM(abalance) FROM Account WHERE uid = :uid ...
     -- if the balance is right, withdrawing is possible...
     ...
   \else
     -- skip silently, the client has left!
   \endif

-- 
Fabien.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [patch] some PQExpBuffer are not destroyed in pg_dump
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Issues with replication slots(which created manually) againstlogical replication