From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Faster "SET search_path" |
Date: | 2023-08-02 05:53:11 |
Message-ID: | a91e1e771cd5ff4b5def11c04402a4548d670410.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2023-08-01 at 22:07 -0700, Nathan Bossart wrote:
> I wonder if this is a good enough reason to _not_ proceed with this
> optimization. At the moment, I'm on the fence about it.
I was wondering the same thing. It's something that could reasonably be
explained to users; it's not what I'd call "magical", it's just
avoiding an unnecessary SET. But I could certainly see it as a cause of
confusion: "why is this query faster for user foo than user bar?".
Another concern is that the default search_path is "$foo, public" but
the safe search_path is "pg_catalog, pg_temp". So if we automatically
switch to the safe search path for functions in index expressions (as I
think we should do, at least ideally), then they'd be slow by default.
We'd need to start advising people to set their search_path to
"pg_catalog, pg_temp" to speed things up.
I'm not opposed to this optimization, but I'm not sure about it either.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-08-02 06:01:15 | Re: Extract numeric filed in JSONB more effectively |
Previous Message | Masahiko Sawada | 2023-08-02 05:34:46 | Re: Adding a LogicalRepWorker type field |