Re: Patch to fix search_path defencies with pg_bench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to fix search_path defencies with pg_bench
Date
Msg-id 7736.1241741468@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to fix search_path defencies with pg_bench  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Patch to fix search_path defencies with pg_bench  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith <gsmith@gregsmith.com> writes:
> On Thu, 7 May 2009, Aidan Van Dyk wrote:
> 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.

No, it is not.  The tables will be created and used in schema 'a',
and the effective search path depth will be the same.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench
Next
From: Josh Berkus
Date:
Subject: [Fwd: congratulations on 8.4 beta]