On Fri, 2023-09-15 at 11:31 -0700, Jeff Davis wrote:
> On Tue, 2023-09-12 at 13:55 -0700, Jeff Davis wrote:
> > On Mon, 2023-08-07 at 15:39 -0700, Nathan Bossart wrote:
> > > 0003 is looking pretty good, too, but I think we
> > > should get some more eyes on it, given the complexity.
> >
> > Attached rebased version of 0003.
>
> Is someone else planning to look at 0003, or should I just proceed?
> It
> seems to be clearly wanted, and I think it's better to get it in this
> 'fest than to wait.
Attaching a new version, as well as some additional optimizations.
Changes:
* I separated it into more small functions, and generally refactored
quite a bit trying to make it easier to review.
* The new version is more careful about what might happen during an
OOM, or in weird cases such as a huge number of distinct search_path
strings.
0003: Cache for recomputeNamespacePath.
0004: Use the same cache to optimize check_search_path().
0005: Optimize cache for repeated lookups of the same value.
Applying the same tests as described in the first message[1], the new
numbers are:
baseline: 4.4s
test query:
without patch: 12.3s
0003: 8.8s
0003,0004: 7.4s
0003,0004,0005: 7.0s
This brings the slowdown from 180% on master down to about 60%. Still
not where we want to be exactly, but more tolerable.
The profile shows a few more areas worth looking at, so I suppose a bit
more effort could bring it down further. find_option(), for instance,
is annoyingly slow because it does case folding.
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com