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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD