On Tue, Sep 16, 2025 at 4:12 PM Robert Haas wrote:
> On Fri, Sep 5, 2025 at 4:19 PM Robert Haas wrote:
> > While mulling this over, I realized that this only works if you don't
> > mind propagating information into the final plan regardless without
> > knowing whether or not EXPLAIN was actually
On 13/9/2025 02:16, Robert Haas wrote:
On Fri, Sep 12, 2025 at 4:34 PM Melanie Plageman
wrote:
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov wrote:
1. Why is it necessary to maintain the GetExplainExtensionId and
GetPlannerExtensionId routines? It seems that using a single
extension_id (rel
On Fri, Sep 5, 2025 at 4:19 PM Robert Haas wrote:
> While mulling this over, I realized that this only works if you don't
> mind propagating information into the final plan regardless without
> knowing whether or not EXPLAIN was actually used. That's pretty sad,
[...]
> The simplest idea that come
On Fri, Sep 12, 2025 at 6:34 PM Melanie Plageman
wrote:
> You're missing a word above -- like "modules to store their own"
> This path does not reflect where you put the file
Thanks.
> Storing a uint32 in a signed int that could be 32-bit stuck out to me.
"git grep pg_nextpower2_32" finds examp
On Mon, Aug 25, 2025 at 3:47 PM Robert Haas wrote:
>
> 0001 is the core "private state" patch for PlannerGlobal, PlannerInfo,
> and RelOptInfo. It is unchanged since v2, and contains only the fix
> for memory context handling since v1. However, I've now tested it, and
> I think it's OK to commit,
Hmm. I don't have a copy of Andrei's email in my gmail. I see it in
the archives but I have not got it. I don't understand how that
happened. I now wonder if there are other emails from Andrei I haven't
received.
On Fri, Sep 12, 2025 at 4:34 PM Melanie Plageman
wrote:
> On Tue, Aug 26, 2025 at 4:
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov wrote:
>
> 1. Why is it necessary to maintain the GetExplainExtensionId and
> GetPlannerExtensionId routines? It seems that using a single
> extension_id (related to the order of the library inside the
> file_scanner) is more transparent and more str
On Mon, Aug 25, 2025 at 3:46 PM Robert Haas wrote:
> 0005 is a demo, not for commit, just to show how these pieces fit
> together. It uses the hooks from 0001 to count the number of times
> set_join_pathlist_hook is called and the number of those that are for
> distinct joinrels. Then it uses plan
On 25/8/2025 21:46, Robert Haas wrote:
On Wed, Aug 20, 2025 at 3:13 PM Robert Haas wrote:
Here's v2. 0001 is what you saw before with an attempt to fix the
memory context handling. 0002 removes join_search_private. All I've
tested is that the tests pass.
Here's v3 with a few more patches. I'm
On Wed, Aug 20, 2025 at 3:13 PM Robert Haas wrote:
> Here's v2. 0001 is what you saw before with an attempt to fix the
> memory context handling. 0002 removes join_search_private. All I've
> tested is that the tests pass.
Here's v3 with a few more patches. I'm now fairly confident I have the
basi
On Tue, Aug 19, 2025 at 2:28 PM Tom Lane wrote:
> You'll presumably have to use GetMemoryChunkContext() for RelOptInfo,
> so I don't see much downside from using it in one or even both of the
> other cases too.
Pointer dereference must be faster than a function call.
> Hm. We don't have read su
On 19/8/2025 18:47, Robert Haas wrote:
polishing. If people do not like this design, then I would like to
know what alternative they would prefer.Thanks for these efforts!
Generally, such an interface seems good for the extension's purposes. It
is OK in this specific context because all these
Robert Haas writes:
> On Tue, Aug 19, 2025 at 1:18 PM Tom Lane wrote:
>> * The initial allocations of the arrays need to take
>> more care than this about which context the arrays go into,
>> ie it had better be planner_cxt for PlannerInfo or PlannerGlobal,
>> and the same context the RelOptInfo
On Tue, Aug 19, 2025 at 1:18 PM Tom Lane wrote:
> This seems generally reasonable to me.
Cool.
> I wonder if we couldn't get rid of PlannerInfo.join_search_private
> in favor of expecting join search hooks to use this mechanism
> (thus, GEQO would become an in-core consumer of the mechanism).
L
Robert Haas writes:
> But that still requires the extension to do a lot of bookkeeping just
> for the privilege of storing some per-query private state, and it
> seems to me that you might well want to store some private state
> per-RelOptInfo or possibly per-PlannerInfo, which seems to require an
I've been working on planner extensibility for some time now, and am
still not quite ready to make a full-fledged proposal, but see
partially-fledged proposals here and here:
http://postgr.es/m/CA+TgmoZY+baV-T-5ifDn6P=L=av-vkvbrpmi0tqkceq-5fi...@mail.gmail.com
http://postgr.es/m/CA+TgmoZxQO8svE_vt
16 matches
Mail list logo
