|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Richard Guo <guofenglinux(at)gmail(dot)com>|
|Cc:||Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com>|
|Subject:||Re: Making Vars outer-join aware|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> ... We can fix
> that by adding an index array to go straight from phid to the
> PlaceHolderInfo. While thinking about where to construct such
> an index array, I decided it'd be a good idea to have an explicit
> step to "freeze" the set of PlaceHolderInfos, at the start of
On further thought, it seems better to maintain the index array
from the start, allowing complete replacement of the linear list
searches. We can add a separate bool flag to denote frozen-ness.
This does have minor downsides:
* Some fiddly code is needed to enlarge the index array at need.
But it's not different from that for, say, simple_rel_array.
* If we ever have a need to mutate the placeholder_list as a whole,
we'd have to reconstruct the index array to point to the new
objects. We don't do that at present, except in one place in
analyzejoins.c, which is easily fixed. While the same argument
could be raised against the v1 patch, it's not very likely that
we'd be doing such mutation beyond the start of deconstruct_jointree.
Hence, see v2 attached.
regards, tom lane
|Next Message||Tom Lane||2022-08-16 21:02:27||Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock|
|Previous Message||Robert Haas||2022-08-16 20:46:59||Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock|