On Thu, 7 May 2009, Aidan Van Dyk wrote:
But by dropping the search_path, you're necessarily changing the catalog
comparisons and lookups anyways, because your now taking a "random"
search path to follow (which could have multiple entries in it) instead
of one guaranteed to be a single, useable entry.
You are correct here. Right now, pgbench is guaranteed to be running
against a search_path with only one entry in it. If someone runs the new
version against a configuration with something like:
search_path='a,b,c,d,e,f,g,h,i,j,public'
instead, that is going to execute more slowly than the current pgbench
would have.
But it seems pretty unlikely such a change would actually be noticable
relative to how much per-transaction overhead and run to run variation
there already is in pgbench for reasonably sized catalogs. Maybe it's
worth adding a quick comment about the issue in the docs, I don't think
this downside is significant enough to worry about beyond that.
I think Joshua's original suggestion here is worth considering a bug fix
for merging into 8.4. As long as testers don't do anything crazy with
their manually set search_path, results should be identical with the
earlier verions.
The additional suggestion of renaming the tables with a prefix is
reasonable to me, but it seems way out of scope for something to consider
applying right now though. If you look at the pgbench client, there's a
lot of string parsing going on in there that's not particularly efficient.
I'd want to see a benchmark aimed that quantifying whether that part
suffers measurably from making the table names all longer before such a
change got applied. And there's already a couple of us who are in the
middle of 8.4 pgbench tests that really don't need disruption like that
thrown into the mix right now.
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
