On Wed, Jul 30, 2025 at 3:17 PM Richard Guo wrote:
> create table t (a int, b int, c int);
>
> explain (costs off)
> select * from t t1
> natural join t t2
> natural join t t3
> natural join t t4
> natural join t t5
> natural join t t6
> natural join t t7
> natural join t t8
> natural join
On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra wrote:
> Does this mean we can close the PG18 open item tracking this?
>
> * virtual generated columns and planning speed
> Owner: Peter Eisentraut
>
>
> If I understand correctly, the commits went only to master, which means
> PG18 still does the
On 7/22/25 04:55, Richard Guo wrote:
> On Wed, Jul 16, 2025 at 10:57 AM Richard Guo wrote:
>> On Wed, Jul 9, 2025 at 3:32 PM Richard Guo wrote:
>>> Here is a new rebase. I moved the call to preprocess_relation_rtes to
>>> a later point within convert_EXISTS_sublink_to_join, so we can avoid
>>> t
On Wed, Jul 16, 2025 at 10:57 AM Richard Guo wrote:
> On Wed, Jul 9, 2025 at 3:32 PM Richard Guo wrote:
> > Here is a new rebase. I moved the call to preprocess_relation_rtes to
> > a later point within convert_EXISTS_sublink_to_join, so we can avoid
> > the work if it turns out that the EXISTS
On Wed, Jul 9, 2025 at 3:32 PM Richard Guo wrote:
> On Mon, Jun 30, 2025 at 4:26 PM Richard Guo wrote:
> > On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
> > > This patchset does not apply anymore due to 2c0ed86d3. Here is a new
> > > rebase.
>
> > This patchset does not apply anymore, due
On Mon, Jun 30, 2025 at 4:26 PM Richard Guo wrote:
> On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
> > This patchset does not apply anymore due to 2c0ed86d3. Here is a new
> > rebase.
> This patchset does not apply anymore, due to 5069fef1c this time.
> Here is a new rebase.
Here is a new
On 3/7/2025 02:30, Richard Guo wrote:
On Wed, Jul 2, 2025 at 6:44 PM Andrei Lepikhov wrote:
I apologise for the confusion in my previous message. I am not
suggesting that we postpone this. Instead, I would like an explanation
of why you believe that accessing the table statistics earlier could
On Wed, Jul 2, 2025 at 6:44 PM Andrei Lepikhov wrote:
> On 2/7/2025 11:14, Richard Guo wrote:
> > On Wed, Jul 2, 2025 at 4:32 PM Andrei Lepikhov wrote:
> >> Therefore, it would be better to find a way to refactor the
> >> `preprocess_relation_rtes` function to gather table statistics lazily
> >>
On 2/7/2025 11:14, Richard Guo wrote:
On Wed, Jul 2, 2025 at 4:32 PM Andrei Lepikhov wrote:
I must say that I appreciate Tom's idea and see significant benefits in
making the parse tree a read-only structure. In complex queries, it can
be frustrating to make copies of the parse tree, leading to
On Wed, Jul 2, 2025 at 4:32 PM Andrei Lepikhov wrote:
> I must say that I appreciate Tom's idea and see significant benefits in
> making the parse tree a read-only structure. In complex queries, it can
> be frustrating to make copies of the parse tree, leading to complaints
> from users about insu
On 2/7/2025 03:24, Richard Guo wrote:
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov wrote:
I like the general idea of this work. But I wonder, why is a new hash
table designed to store only the notnullattnums field? From the
discussion, it is not apparent why not to cache all (or most of) the
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov wrote:
> I like the general idea of this work. But I wonder, why is a new hash
> table designed to store only the notnullattnums field? From the
> discussion, it is not apparent why not to cache all (or most of) the
> data needed for get_relation_inf
On 30/6/2025 09:26, Richard Guo wrote:
On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
Yeah, this patchset is targeted for v19. Maybe we could be more
aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
This patchset does not apply anymore due to 2c0ed86d3. Here is a ne
On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
> Yeah, this patchset is targeted for v19. Maybe we could be more
> aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
>
> This patchset does not apply anymore due to 2c0ed86d3. Here is a new
> rebase.
This patchset does not
On Thu, May 22, 2025 at 11:51 PM Tom Lane wrote:
> BTW, in my mind the current thread is certainly v19 material,
> so I have not looked at Richard's patch yet.
Yeah, this patchset is targeted for v19. Maybe we could be more
aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
On Thu, May 22, 2025 at 11:51 PM Tom Lane wrote:
> I wonder if a better answer would be to make the rewriter responsible
> for this. If you hold your head at the correct angle, a table with
> virtual generated columns looks a good deal like a view, and we don't
> ask the planner to handle those.
Robert Haas writes:
> Before we commit to something along these lines, I think we need to
> understand whether Tom intends to press Peter for some bigger change
> around expand_virtual_generated_columns.
> If Tom doesn't respond right away, I suggest that we need to add an
> open item for http://p
On Thu, May 1, 2025 at 4:33 AM Richard Guo wrote:
> Here is the patchset that implements this optimization. 0001 moves
> the expansion of virtual generated columns to occur before sublink
> pull-up. 0002 introduces a new function, preprocess_relation_rtes,
> which scans the rangetable for relati
On Sat, May 3, 2025 at 7:48 PM Chengpeng Yan wrote:
> I've been following the V4 patches (focusing on 1 and 2 for now): Patch 2's
> preprocess_relation_rtes is a nice improvement for efficiently gathering
> early catalog info like inh and attgenerated definitions in one pass.
>
> However, Patch
> On May 1, 2025, at 16:33, Richard Guo wrote:
>
> Here is the patchset that implements this optimization. 0001 moves
> the expansion of virtual generated columns to occur before sublink
> pull-up. 0002 introduces a new function, preprocess_relation_rtes,
> which scans the rangetable for rel
On Fri, Apr 11, 2025 at 3:51 PM Richard Guo wrote:
> On Fri, Apr 11, 2025 at 4:45 AM Robert Haas wrote:
> > OK. Maybe I shouldn't be worrying about the table_open() /
> > table_close() here, because I see that you are right that
> > has_subclass() is nearby, which admittedly does not involve open
On Fri, Apr 11, 2025 at 4:45 AM Robert Haas wrote:
> OK. Maybe I shouldn't be worrying about the table_open() /
> table_close() here, because I see that you are right that
> has_subclass() is nearby, which admittedly does not involve opening
> the relation, but it does involve fetching from the sy
Robert Haas writes:
> It's not quite the same complaint, because the earlier complaint was
> that it was actually being done at parse time, and this complaint is
> that it is scribbling on a parse-time data structure.
Ah, right. But that's still not the direction we want to be
going in [1].
On Thu, Apr 10, 2025 at 3:54 PM Tom Lane wrote:
> > A related point that I'm noticing is that you record the not-NULL
> > information in the RangeTblEntry.
>
> Did we not just complain about that w.r.t. the v1 version of this
> patch? RangeTblEntry is not where to store this info. We need
> a ne
Robert Haas writes:
> OK. Maybe I shouldn't be worrying about the table_open() /
> table_close() here, because I see that you are right that
> has_subclass() is nearby, which admittedly does not involve opening
> the relation, but it does involve fetching from the syscache a tuple
> that we wouldn
On Sun, Apr 6, 2025 at 10:59 PM Richard Guo wrote:
> That's correct. As I mentioned earlier, I believe attnotnull isn't
> the only piece of information we need to gather early on. My general
> idea is to separate the collection of catalog information into two
> phases:
>
> * Phase 1 occurs at an
On Sat, Apr 5, 2025 at 4:14 AM Robert Haas wrote:
> On Tue, Apr 1, 2025 at 10:14 PM Richard Guo wrote:
> > The attnotnull catalog information being discussed here is intended
> > for use during constant folding (and possibly sublink pull-up), which
> > occurs long before partition pruning. Am I
On Fri, Mar 21, 2025 at 10:21 AM Tom Lane wrote:
> Robert Haas writes:
> > However, I'm a bit concerned about the overall premise of the patch
> > set. It feels like it is moving something that really ought to happen
> > at optimization time back to parse time. I have a feeling that's going
> >
Currently, we have an optimization that reduces an IS [NOT] NULL qual
on a NOT NULL column to constant true or constant false, provided we
can prove that the input expression of the NullTest is not nullable by
any outer joins. This deduction happens pretty late in planner,
during the distribution
On Fri, Mar 21, 2025 at 6:14 PM Richard Guo wrote:
> I'm wondering whether we can collect that information while building
> the RangeTblEntry for a base or other relation, so that it's available
> before constant folding. This could also enable other optimizations,
> such as checking if a NOT IN
On Tue, Apr 1, 2025 at 10:14 PM Richard Guo wrote:
> The attnotnull catalog information being discussed here is intended
> for use during constant folding (and possibly sublink pull-up), which
> occurs long before partition pruning. Am I missing something?
Hmm, OK, so you think that we need to g
On Tue, Apr 1, 2025 at 2:34 AM Richard Guo wrote:
> However, I gave up this idea because I realized it would require
> retrieving a whole bundle of catalog information that isn't needed
> until after the RelOptInfos are built, such as max_attr, pages,
> tuples, reltablespace, parallel_workers, ext
On Wed, Apr 2, 2025 at 4:34 AM Robert Haas wrote:
> On Tue, Apr 1, 2025 at 2:34 AM Richard Guo wrote:
> > However, I gave up this idea because I realized it would require
> > retrieving a whole bundle of catalog information that isn't needed
> > until after the RelOptInfos are built, such as max_
On Tue, Apr 1, 2025 at 1:55 AM Robert Haas wrote:
> As a general principle, I have found that it's usually a sign that
> something has been designed poorly when you find yourself wanting to
> open a relation, get exactly one piece of information, and close the
> relation again. That is why, today,
On Thu, Mar 27, 2025 at 10:08 AM Richard Guo wrote:
> On Thu, Mar 27, 2025 at 10:53 PM Tom Lane wrote:
> > Richard Guo writes:
> > > I'm planning to push this patch soon, barring any objections.
>
> > FWIW, I have not reviewed it at all.
>
> Oh, sorry. I'll hold off on pushing it.
As a general
On Thu, Mar 27, 2025 at 10:53 PM Tom Lane wrote:
> Richard Guo writes:
> > I'm planning to push this patch soon, barring any objections.
> FWIW, I have not reviewed it at all.
Oh, sorry. I'll hold off on pushing it.
Thanks
Richard
Richard Guo writes:
> I'm planning to push this patch soon, barring any objections.
FWIW, I have not reviewed it at all.
regards, tom lane
On Wed, Mar 26, 2025 at 6:45 PM David Rowley wrote:
> On Wed, 26 Mar 2025 at 19:31, Richard Guo wrote:
> > On Wed, Mar 26, 2025 at 3:06 PM Tender Wang wrote:
> > > The comment about notnullattnums in struct RangeTblEntry says that:
> > > * notnullattnums is zero-based set containing attnums of
On Fri, Mar 21, 2025 at 10:21 AM Richard Guo wrote:
> Not quite sure if this is something we need to worry about.
I haven't really dug into this but I bet it's not that serious, in the
sense that we could probably work around it with more logic if we
really need to.
However, I'm a bit concerned
On Wed, 26 Mar 2025 at 19:31, Richard Guo wrote:
>
> On Wed, Mar 26, 2025 at 3:06 PM Tender Wang wrote:
> > The comment about notnullattnums in struct RangeTblEntry says that:
> > * notnullattnums is zero-based set containing attnums of NOT NULL
> > * columns.
> >
> > But in get_relation_notnull
Richard Guo 于2025年3月26日周三 10:16写道：
> On Sun, Mar 23, 2025 at 6:25 PM Richard Guo
> wrote:
> > On Sat, Mar 22, 2025 at 2:21 AM Tom Lane wrote:
> > > The way to make this work is what I said before: move the planner's
> > > collection of relation information to somewhere a bit earlier in
> > > th
On Wed, Mar 26, 2025 at 3:06 PM Tender Wang wrote:
> The comment about notnullattnums in struct RangeTblEntry says that:
> * notnullattnums is zero-based set containing attnums of NOT NULL
> * columns.
>
> But in get_relation_notnullatts():
> rte->notnullattnums = bms_add_member(rte->notnullattnu
On Sun, Mar 23, 2025 at 6:25 PM Richard Guo wrote:
> On Sat, Mar 22, 2025 at 2:21 AM Tom Lane wrote:
> > The way to make this work is what I said before: move the planner's
> > collection of relation information to somewhere a bit earlier in
> > the planner. But not to outside the planner.
> I'
On Sat, Mar 22, 2025 at 2:21 AM Tom Lane wrote:
> Ugh, no, that is *completely* unworkable. Suppose that the user
> does CREATE VIEW, and the parse tree recorded for that claims that
> column X is not-nullable. Then the user drops the not-null
> constraint, and then asks to execute the view. We
On Sat, Mar 22, 2025 at 1:12 AM Robert Haas wrote:
> However, I'm a bit concerned about the overall premise of the patch
> set. It feels like it is moving something that really ought to happen
> at optimization time back to parse time. I have a feeling that's going
> to break something, although I
Robert Haas writes:
> However, I'm a bit concerned about the overall premise of the patch
> set. It feels like it is moving something that really ought to happen
> at optimization time back to parse time. I have a feeling that's going
> to break something, although I am not sure right now exactly
46 matches
Mail list logo
