On Tue, Feb 16, 2016 at 1:55 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Feb 16, 2016 at 9:18 AM, Robert Haas <robertmh...@gmail.com> wrote: >> I experimented with trying to do this and ran into a problem: where >> exactly would you store the evaluated arguments when you don't know >> how many of them there will be? And even if you did know how many of >> them there will be, wouldn't that mean that evalFunc or evaluateExpr >> would have to palloc a buffer of the correct size for each invocation? >> That's far more heavyweight than the current implementation, and >> minimizing CPU usage inside pgbench is a concern. It would be >> interesting to do some pgbench runs with this patch, or the final >> patch, and see what effect it has on the TPS numbers, if any, and I >> think we should. But the first concern is to minimize any negative >> impact, so let's talk about how to do that. > > Good point. One simple idea here would be to use a custom pgbench > script that has no SQL commands and just calculates the values of some > parameters to measure the impact without depending on the backend, > with a fixed number of transactions.
Sure, we could do that. But whether it materially changes pgbench -S results, say, is a lot more important. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
