Re: Patch to fix search_path defencies with pg_bench

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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD