From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic plans and "initial" pruning |
Date: | 2022-07-29 16:47:05 |
Message-ID: | 3819649.1659113225@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... it's
> always struck me as a little unfortunate that we basically test
> whether a var is equal by testing whether the varno and varlevelsup
> are equal. That only works if you assume that you can never end up
> comparing two vars from thoroughly unrelated parts of the tree, such
> that the subquery one level up from one might be different from the
> subquery one level up from the other.
Yeah, that's always bothered me a little as well. I've yet to see a
case where it causes a problem in practice. But I think that if, say,
we were to try to do any sort of cross-query-level optimization, then
the ambiguity could rise up to bite us. That might be a situation
where a flat rangetable would be worth the trouble.
> I'm just uncertain whether what Amit has implemented is the
> least-annoying way to go about it... any thoughts on that,
> specifically as it pertains to this patch?
I haven't looked at this patch at all. I'll try to make some
time for it, but probably not today.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-07-29 16:52:50 | Re: Temporary file access API |
Previous Message | Reid Thompson | 2022-07-29 16:43:45 | Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated |