On Wed, Dec 18, 2024 at 7:05 AM Tom Lane wrote:
> David Rowley writes:
> > The slightly annoying thing here is that the attached patch passes the
> > TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> > Append does not go to much effort to setting a fixed
> > TupleTableSlotOps
On Thu, Dec 19, 2024 at 8:18 AM Melanie Plageman
wrote:
> I pushed the straightforward option for now so that it's fixed.
I think this binary search code now has a risk of underflow. If 'mid'
is calculated as zero, the second 'if' branch will cause 'end' to
underflow.
Maybe we need to do someth
On Wed, Dec 18, 2024 at 7:45 PM David Rowley wrote:
> On Wed, 18 Dec 2024 at 22:29, Richard Guo wrote:
> > Should we be concerned about passing a NULL TupleTableSlotOps in
> > nodeRecursiveUnion.c?
>
> I made it pass NULL on purpose because the slot type on the recursive
>
On Thu, Dec 19, 2024 at 8:10 AM Tom Lane wrote:
> David Rowley writes:
> > I propose to quickly do a master-only follow-up commit to use the
> > inputOps instead of NULL in BuildTupleHashTableExt (Basically Tom's
> > patch from [1])
>
> LGTM.
+1.
Thanks
Richard
On Thu, Dec 19, 2024 at 6:15 PM Richard Guo wrote:
> I think we need to check whether rs_tbmiterator is NULL before calling
> tbm_end_iterate on it, like below.
>
> --- a/src/backend/executor/nodeBitmapHeapscan.c
> +++ b/src/backend/executor/nodeBitmapHeapscan.c
>
On Sat, Oct 19, 2024 at 5:48 AM Melanie Plageman
wrote:
> I plan to commit 0002 and 0003 next week. I'm interested if you think
> 0001 is correct.
> I may also commit 0004-0006 as I feel they are ready too.
I noticed an oversight on master, which I think was introduced by the
0005 patch. In Exec
On Fri, Dec 20, 2024 at 7:50 AM Melanie Plageman
wrote:
> On Wed, Dec 18, 2024 at 9:50 PM Richard Guo wrote:
> > I think this binary search code now has a risk of underflow. If 'mid'
> > is calculated as zero, the second 'if' branch will cause 'end'
On Sat, Jan 18, 2025 at 6:16 AM Robert Haas wrote:
> On Thu, Jan 16, 2025 at 3:18 AM Richard Guo wrote:
> > If this t1/t2 join is part of a larger SELECT query, I think the cost
> > estimates for the upper join nodes would likely be quite inaccurate.
>
> That's def
On Tue, Jan 21, 2025 at 2:57 AM Tom Lane wrote:
> However, a partial-aggregation path does not generate the same data
> as an unaggregated path, no matter how fuzzy you are willing to be
> about the concept. So I'm having a very hard time accepting that
> it ought to be part of the same RelOptInf
On Tue, Jan 21, 2025 at 1:28 AM Robert Haas wrote:
> On Sun, Jan 19, 2025 at 7:53 AM Richard Guo wrote:
> > If, at last, the conclusion of this discussion is that we should not
> > apply this change until we fix those problems in aggregate estimates,
> > I'd be ver
(This was briefly discussed in [1], which primarily focuses on the
incremental sort regression. So start a new thread for this topic.)
In set_append_rel_size(), we currently set rel->tuples to rel->rows
for an appendrel. Generally, rel->tuples is the raw number of tuples
in the relation and rel-
On Wed, Jan 22, 2025 at 1:36 AM Robert Haas wrote:
> Thanks for the example. What seems to be happening here is that each
> of the three joins increases the number of rows by a multiple of
> either 166 or 333. Aggregating reduces the number of rows to 3. I am
> not sure that we should be too conce
On Fri, Sep 27, 2024 at 5:06 AM Tom Lane wrote:
> So I'm worried that the point about lateral refs is still a problem
> in your version. To be clear, the hazard is that if a WHERE clause
> ends up getting placed at an outer join that's higher than any of
> the OJs specifically listed in its requi
On Tue, Dec 31, 2024 at 5:40 PM Richard Guo wrote:
> Regarding the back-patch, this patch is a bug fix, which suggests it
> should be back-patched. However, it also changes some plans by fixing
> the cost estimation. Does anyone know what our usual approach is in
> this situatio
On Fri, Dec 27, 2024 at 1:16 PM Richard Guo wrote:
> I'm wondering if we also need to strip out the nullingrels from the
> expression in examine_variable(). I tried doing so and noticed a plan
> diff in regression test join.sql.
Here is an updated patch that implements this ch
On Wed, Dec 25, 2024 at 5:14 PM Richard Guo wrote:
> On Wed, Dec 25, 2024 at 11:34 AM Andrei Lepikhov wrote:
> > 2. It is ok for Vars. But what about expressions? We use equal() in
> > distinct, MCV and dependencies modules. Do we need to remove nulls
> > before using ext
On Wed, Dec 25, 2024 at 11:34 AM Andrei Lepikhov wrote:
> I have a couple of notes.
> 1. The nulling_relids provides us sensible information about possible
> nulls inside the input. We are not using it to estimate the number of
> such nulls for now. Does Your idea consist of obtaining 'clear'
> st
On Tue, Dec 24, 2024 at 5:00 PM Richard Guo wrote:
> It seems to me that when estimating the number of groups, we do not
> need to concern ourselves with the outer joins that could null the
> Vars/PHVs contained in the grouping expressions, and we should not
> count the same Var mo
On Wed, Jan 15, 2025 at 12:07 AM Robert Haas wrote:
> On Sun, Jan 12, 2025 at 9:04 PM Richard Guo wrote:
> > Attached is an updated version of this patch that addresses Jian's
> > review comments, along with some more cosmetic tweaks. I'm going to
> > be looki
On Wed, Jan 15, 2025 at 11:40 PM Robert Haas wrote:
> On Wed, Jan 15, 2025 at 1:58 AM Richard Guo wrote:
> > I understand that we're currently quite bad at estimating the number
> > of groups after aggregation. In fact, it's not just aggregation
> > estimates — w
On Fri, Jan 17, 2025 at 6:40 AM Tom Lane wrote:
> * The README addition, and the basically identical text in the
> commit message, don't even provide a reason to believe that the
> transformation is correct let alone that it will result in faster
> execution. I don't understand why it's so hard t
On Thu, Jan 9, 2025 at 12:15 PM jian he wrote:
> hi.
> in create_grouping_expr_infos
>
> tce = lookup_type_cache(exprType((Node *) tle->expr),
> TYPECACHE_BTREE_OPFAMILY);
> if (!OidIsValid(tce->btree_opf) ||
> !OidIsValid(tce->btree_opin
On Fri, Jan 17, 2025 at 12:28 AM Dean Rasheed wrote:
> I went over this again in detail and didn't find any problems, so I
> have committed it. Thanks for all the review comments.
It seems that adding ParseNamespaceItems for the OLD or NEW aliases
may confuse scanNameSpaceForRelid() when searchin
On Mon, Feb 10, 2025 at 5:22 PM Richard Guo wrote:
> Thanks for all the reviews. Attached is an updated patch that
> resolves the review comments.
Pushed. Thanks for all the reviews.
Thanks
Richard
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
While working on another patch, I looked at ChangeVarNodes() and found
some issues introduced by the self-join elimination commit. I think
it'd better to fix or improve them.
* ChangeVarNodes_walker includes special handling for RestrictInfo
nodes. And it adjusts RestrictInfo.orclause only if th
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 a
On Mon, Mar 24, 2025 at 9:59 AM Richard Guo wrote:
> On Mon, Mar 24, 2025 at 9:54 AM Michael Paquier wrote:
> > On Mon, Mar 24, 2025 at 09:50:36AM +0900, Richard Guo wrote:
> > > Nice catch. The fix looks good to me. It seems to me that it's fine
> > > to go wi
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
On Sat, Mar 29, 2025 at 1:38 AM Kirill Reshke wrote:
> On Fri, 28 Mar 2025 at 15:19, Richard Guo wrote:
> > On Fri, Mar 28, 2025 at 4:53 PM Kirill Reshke
> > wrote:
> > > On Fri, 28 Mar 2025 at 09:47, jian he wrote:
> > > > The first "Also ignore if N
FWIW, I reported some issues with this commit in [1]. Any thoughts on
how to fix them?
[1]
https://www.postgresql.org/message-id/flat/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com
Thanks
Richard
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 par
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
On Fri, Feb 21, 2025 at 7:04 PM Ilia Evdokimov
wrote:
> When calculating selectivity for an inner equijoin, we call
> eqjoinsel_inner, which uses unused parameters vardata1 and vardata2.
> These parameters might have been left behind accidentally when we moved
> getting sslots out of the function.
On Mon, Apr 7, 2025 at 9:54 PM Andrei Lepikhov wrote:
> On 4/7/25 09:50, Richard Guo wrote:
> > Consider the join to t3. It is a unique join, and not all of its
> > restriction clauses are parameterized. Despite this, the check still
> > passes.
> At the same time I t
On Wed, Apr 9, 2025 at 6:18 PM David Rowley wrote:
> On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
> > Perhaps we could spend some planner cycles proving inner_unique for
> > anti joins, so that Memoize nodes can be considered for them?
> Worth a try. It should be pretty
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 Mon, Mar 31, 2025 at 7:33 PM Andrei Lepikhov wrote:
> and I don't get the case. As I see, ANTI/SEMI join just transforms to
> the regular join and it is still not the case. May you be more specific?
Upthread, you said that a qual contained in ppi_clauses will also be
included in extra->restric
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 RelO
On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed wrote:
> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
> > On 4/4/25 09:37, Richard Guo wrote:
> > > With more exposure to the changes in ChangeVarNodes(), I have some
> > > more concerns. As I understand it, Chan
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
While reviewing another patch [1], I noticed an incorrect check in
get_memoize_path.
if (extra->inner_unique &&
(inner_path->param_info == NULL ||
bms_num_members(inner_path->param_info->ppi_serials) <
list_length(extra->restrictlist)))
return NULL;
This chec
On Thu, May 1, 2025 at 12:49 AM Japin Li wrote:
> While working on [1], I found outdated comments in IndexInfo.
> The attached patch corrects them.
Nice catch. LGTM.
Thanks
Richard
On Fri, Apr 11, 2025 at 3:47 AM Robert Haas wrote:
> I'd probably write the increments as ++ rather than += 1 but I'm not
> sure if everyone would agree.
I'm a fan of ++ as well, so I agree.
Thanks
Richard
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
On Sat, Apr 12, 2025 at 5:26 AM Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
>
> Please join us in wishing Jacob much success and few reverts!
Congratulations Jacob
On Mon, Apr 7, 2025 at 4:50 PM Richard Guo wrote:
> Hence, I propose the attached patch for the fix.
>
> BTW, there is a XXX comment there saying that maybe we can make the
> remaining join quals part of the inner scan's filter instead of the
> join filter. I don't thin
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
> I noticed this recoveryCheck test failure on flaviventris after
> pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
>
> ### Reloading node "standby"
> # Running: pg_ctl --pgdata xxx/pgdata
On Fri, Mar 28, 2025 at 7:12 PM Евгений Горбанев wrote:
> If you replace is_not_null with NOT NULL in the query, everything works
> correctly.
> It seems that is_not_null is an incorrect keyword and it should not be
> used, but I don't understand how it gets here.
It seems what happens is that in
On Wed, Apr 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> 16.04.2025 06:05, Richard Guo wrote:
> On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
> I noticed this recoveryCheck test failure on flaviventris after
> pushing commit 3b35f9a4c (Fix an incorrect check in get_
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 a
On Sun, Apr 6, 2025 at 1:46 AM Tom Lane wrote:
> The parser, rewriter, and planner all have a bad habit of scribbling
> on their input parsetrees. At this point I've lost count of how many
> bugs that's caused (but e33f2335a and 0f43083d1 are the two latest
> examples), and of how many places the
On Mon, Apr 14, 2025 at 8:08 PM wenhui qiu wrote:
> No objections.It's a pity that the postgresql18 version has been code-frozen
v18 is now in feature freeze, but not code freeze, so bug fixes are
still allowed. I've pushed this patch after adding the "Reviewed-by"
tags.
Thanks
Richard
I noticed this recoveryCheck test failure on flaviventris after
pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
### Reloading node "standby"
# Running: pg_ctl --pgdata xxx/pgdata reload
server signaled
### Restarting node "standby"
# Running: pg_ctl --wait --pgdata xxx/pgdat
On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote:
> On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote:
> > I'm wondering if we should consider mentioning that several
> > long-standing issues related to grouping sets have been fixed starting
> > from PostgreS
On Tue, Feb 4, 2025 at 4:59 PM Richard Guo wrote:
> On Thu, Nov 7, 2024 at 7:07 PM Tender Wang wrote:
> > While learning gist index insert codes, I find a little issue with
> > BufferGetLSNAtomic().
> > At first, it wants to get bufHdr by accessing the buffer descriptor
On Wed, Feb 19, 2025 at 9:58 AM Richard Guo wrote:
> On Wed, Feb 19, 2025 at 9:44 AM Michael Paquier wrote:
> > On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote:
> > > I plan to push this shortly. This is arguably a bug, but it hasn't
> > > caused
On Wed, Feb 19, 2025 at 9:44 AM Michael Paquier wrote:
> On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote:
> > I plan to push this shortly. This is arguably a bug, but it hasn't
> > caused any real issues, and nobody has complained about it until now,
> > so
On Tue, Feb 18, 2025 at 7:09 PM Richard Guo wrote:
> It seems to me that, for a relation in the rangetable that has virtual
> generated columns, we can consider it a subquery to some extent. For
> instance, suppose we have a query:
>
> select ... from ... join t on ...;
>
>
On Sat, Feb 15, 2025 at 9:37 PM Dean Rasheed wrote:
> On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
> > Maybe a short-term fix would be to error out if we find ourselves about
> > to expand a Var with varnullingrels != NULL. That would mean you
> > couldn't use a virtual generated column
On Wed, Feb 26, 2025 at 7:09 PM Tender Wang wrote:
> Recently, I found Greenplum implement pull-up NOT IN subquery. They have the
> below comments in their codes:
>
> We normalize NOT subqueries using the following axioms:
> *
> * val NOT IN (subq) => val <> ALL (subq)
>
> Richard, do you have a
On Thu, Feb 27, 2025 at 6:58 AM Tom Lane wrote:
> Yeah. The key problem blocking doing something about it in the
> planner is that at the time we want to do join tree restructuring,
> we haven't yet collected the per-relation data that would allow
> us to know about NOT NULL constraints, nor run
On Wed, Mar 5, 2025 at 8:01 PM Dean Rasheed wrote:
> Yes, that makes sense, and it seems like a fairly straightforward
> simplification, given that perform_pullup_replace_vars() sets it back
> to false shortly afterwards.
>
> The same thing happens in pull_up_constant_function().
Thanks for looki
On Wed, Mar 12, 2025 at 1:32 AM Dean Rasheed wrote:
> On Mon, 10 Mar 2025 at 13:05, Richard Guo wrote:
> > Attached are the patches.
> These 2 comment changes from 0002 could be made part of 0001:
>
> 1). In pull_up_simple_subquery(), removing the word "Again" from
On Wed, Mar 5, 2025 at 11:02 AM Richard Guo wrote:
> It seems to me that simple Var expressions in a subquery's target list
> also need to retain their separate identity in order to match grouping
> set columns after subquery pullup, not just non-var expressions.
I noticed the adja
On Wed, Mar 5, 2025 at 11:02 AM Richard Guo wrote:
> create table t (a int);
> insert into t values (1);
>
> # select a, b
> from (select a, a as b from t) ss
> group by grouping sets(a, b)
> having b = 1;
> a | b
> ---+---
> 1 |
> (1 row)
>
> Note
While working on the expansion of virtual generated columns, Dean
encountered $subject in [1], which can be reproduced using the query
below.
create table t (a int);
insert into t values (1);
# select a, b
from (select a, a as b from t) ss
group by grouping sets(a, b)
having b = 1;
a | b
-
On Wed, Mar 12, 2025 at 6:29 PM Dean Rasheed wrote:
> On Wed, 12 Mar 2025 at 07:45, Richard Guo wrote:
> > For backpatching, 0001 seems more like a cosmetic change, and I don't
> > think it needs to be backpatched. 0002 is a bug fix, but I'm not
> > confident
On Thu, Feb 20, 2025 at 12:25 AM Dean Rasheed wrote:
> On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
> > One thing I don't like about this is that it's introducing more code
> > duplication between pullup_replace_vars() and
> > ReplaceVarsFromTargetList(). Those already had a lot of code in c
On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> Attached are the updated patches to fix all the mentioned issues. I
> plan to push them early next week after staring at the code for a bit
> longer, barring any objections.
Sign... I neglected to make the change in 0001 that a Va
On Mon, Feb 24, 2025 at 9:07 PM Dean Rasheed wrote:
> On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote:
> > Here are the updated patches with revised comments and some tweaks to
> > the commit messages. I plan to push them in one or two days.
> LGTM.
Pushed. Thanks all f
On Mon, Feb 24, 2025 at 3:50 PM jian he wrote:
> On Sat, Feb 22, 2025 at 11:12 PM Richard Guo wrote:
> > On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> > > Attached are the updated patches to fix all the mentioned issues. I
> > > plan to push them early nex
On Sat, Feb 22, 2025 at 2:35 AM Dean Rasheed wrote:
> On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote:
> > * The expansion of virtual generated columns occurs after subquery
> > pullup, which can lead to issues. This was an oversight on my part.
> > Initially, I believed i
On Tue, Feb 25, 2025 at 1:30 AM Robert Haas wrote:
> On Mon, Feb 24, 2025 at 8:08 AM wenhui qiu wrote:
> > Actually ,Many fork postgresql databases have already implemented ,For
> > example, if the relevant field has a non-null constraint ，Many databases
> > can do the same thing as not exi
On Mon, Mar 31, 2025 at 6:46 PM Andrei Lepikhov wrote:
> On 3/31/25 11:03, Richard Guo wrote:
> > I reviewed this patch and I have some concerns about the following
> > code:
> >
> > if (extra->inner_unique &&
> > (inner_path->para
On Mon, Mar 31, 2025 at 6:39 PM David Rowley wrote:
> On Mon, 31 Mar 2025 at 22:03, Richard Guo wrote:
> > I reviewed this patch and I have some concerns about the following
> > code:
> >
> > if (extra->inner_unique &&
>
On Wed, Apr 2, 2025 at 10:26 PM Richard Guo wrote:
> This is not a thorough review of the code; I just randomly looked at
> ChangeVarNodes(). It's possible that there are other issues that
> haven't been discovered, but I think we should at least fix these.
> I'll pr
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
On Sun, Mar 23, 2025 at 10:41 PM Kevin K Biju wrote:
> int i;
> ...
> for (i = 2; i <= iterations; i++)
> {
> ...
> }
>
> For iterations = INT_MAX, the loop will never terminate since the condition
> is <= and adding 1 to INT_MAX will lead to i wrapping around to INT_MIN.
>
> I've fixed this
On Mon, Mar 24, 2025 at 9:54 AM Michael Paquier wrote:
> On Mon, Mar 24, 2025 at 09:50:36AM +0900, Richard Guo wrote:
> > Nice catch. The fix looks good to me. It seems to me that it's fine
> > to go without a test case, since the fix is quite straightforward.
>
> One
On Fri, Mar 28, 2025 at 4:53 PM Kirill Reshke wrote:
> On Fri, 28 Mar 2025 at 09:47, jian he wrote:
> > The first "Also ignore if NO INHERIT and we weren't told that that's
> > safe." is duplicated,
> > also it's in the wrong place?
> > The second one is fine.
> Hi! Indeed. Looks like an oversig
On Fri, Mar 28, 2025 at 4:40 PM Евгений Горбанев wrote:
> Got an assert failure when fuzzing the raw_parser function.
> The query to reproduce:
> SELECT xmltable.* FROM xmltest2, LATERAL xmltable('/d/r' PASSING x
> COLUMNS a int PATH '' || lower(_path) is_not_null|| 'c');
>
> If I understand corre
On Fri, Mar 28, 2025 at 6:05 PM Richard Guo wrote:
> Nice catch. Yeah, is_not_null is a valid column option in xmltable.
> In you example, the value of the is_not_null option is "|| 'c'", which
> is interpreted as an A_Expr.
>
> I wonder if the value's typ
On Fri, Apr 4, 2025 at 1:02 AM Alexander Korotkov wrote:
> I've got an off-list bug report from Alexander Lakhin involving a
> placeholder variable. Alena and Andrei proposed a fix. It is fairly
> simple: we just shouldn't remove PHVs during self-join elimination, as
> they might still be refere
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-base
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
On Wed, Apr 2, 2025 at 11:39 AM Richard Guo wrote:
> The change looks good to me. I plan to push it soon, barring any
> objections.
Pushed.
Thanks
Richard
For ordered Append or MergeAppend, it seems that incremental sort is
currently not considered when injecting an explicit sort into subpaths
that are not sufficiently ordered. For instance:
set enable_seqscan to off;
explain (costs off)
select hundred as x, two as y from tenk1
union all
select th
On Mon, Apr 14, 2025 at 5:45 PM Richard Guo wrote:
> It seems what happens is that internally in gram.y (~line 14274), the
> DefElem for the not-null option is assigned the name "is_not_null".
> As a result, this allows users to explicitly use "is_not_null" as the
While adding a new field to PlannerGlobal in another patch, I noticed
that although most fields are explicitly initialized, a few are not.
This doesn't cause any functional issues, since makeNode() zeroes all
fields by default. However, the inconsistency stood out to me, so I
wrote the attached pa
On Fri, May 9, 2025 at 12:18 AM Bruce Momjian wrote:
> On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote:
> > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote:
> > > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote:
> > > > I'm wonderi
On Fri, May 9, 2025 at 11:47 AM Richard Guo wrote:
> On Fri, May 9, 2025 at 12:18 AM Bruce Momjian wrote:
> > On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote:
> > > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote:
> > > > On Wed, May 7, 2025 at
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 Fri, May 2, 2025 at 11:44 AM Bruce Momjian wrote:
>
> I have committd the first draft of the PG 18 release notes.
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Thanks for working on these.
I'
On Tue, May 13, 2025 at 8:26 PM David Rowley wrote:
> On Tue, 13 May 2025 at 04:03, Richard Guo wrote:
> > While adding a new field to PlannerGlobal in another patch, I noticed
> > that although most fields are explicitly initialized, a few are not.
> > This doesn't c
On Tue, May 13, 2025 at 10:51 PM Andres Freund wrote:
> This is failing on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5636
> https://api.cirrus-ci.com/v1/artifact/task/5411026402803712/testrun/build-32/testrun/regress/regress/regression.diffs
>
> diff -U3 /tmp/cirrus-ci-bu
On Fri, May 9, 2025 at 6:50 PM Alvaro Herrera wrote:
> I agree that blocking the index from using the option name that xmltable
> parsing uses internally is okay. Maybe we can rename it to something
> like "__pg__is_not_null" or something like that, which would reduce the
> chances of troubling p
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)
801 - 900 of 934 matches
Mail list logo
