On Mon, Sep 22, 2025 at 9:53 AM David Rowley wrote:
> On Mon, 22 Sept 2025 at 11:59, Richard Guo wrote:
> > On Mon, Sep 22, 2025 at 8:10 AM Chao Li wrote:
> > > When gin_tuple.h was introduced by commit 8492feb[1], the file header
> > > comment incorrectly referred t
On Mon, Sep 22, 2025 at 8:10 AM Chao Li wrote:
> When gin_tuple.h was introduced by commit 8492feb[1], the file header comment
> incorrectly referred to gin.h. Update the comment to mention gin_tuple.h
> instead.
Indeed. Will push the patch.
- Richard
On Sun, Sep 21, 2025 at 11:54 PM Steve Lau wrote:
> Found a tiny incorrect comment of RangeTblEntry, field "alias" is actually
> above "join_using_alias", so the code comment could be updated to reflect the
> current field order:
>
> > join_using_alias is an alias clause attached directly to JOI
On Fri, Sep 5, 2025 at 10:12 PM Robert Haas wrote:
> On Wed, Aug 6, 2025 at 3:52 AM Richard Guo wrote:
> > What we really want to exclude are aggregate functions that can
> > produce large transition values by accumulating or concatenating input
> > rows. So I'm won
On Sat, Sep 6, 2025 at 1:00 AM Tom Lane wrote:
> Robert Haas writes:
> > I was not aware of outer_join_rels, so thank you for pointing it out.
> > However, consider this query:
>
> > select 1 from pg_class a inner join pg_class b on a.relfilenode =
> > b.relfilenode;
>
> > Here, we end up with a
On Sat, Sep 13, 2025 at 2:32 AM Robert Haas wrote:
> We sort of got started down this path because, reviewing v4-0003,
> Richard commented that I might be able to sanity-check
> something-or-other about RTE_JOIN RTIs instead of just focusing on
> baserels. From there, this sub-thread has turned in
On Sat, Sep 13, 2025 at 12:08 AM Tom Lane wrote:
> After thinking about this for awhile, I believe that Richard and I
> each had half of the right solution ;-). Let me propose some new
> terminology in hopes of clarifying matters:
>
> * A join plan node "starts" an outer join if it performs the
>
On Sat, Sep 13, 2025 at 3:48 AM Robert Haas wrote:
> On Fri, Sep 12, 2025 at 5:34 AM Richard Guo wrote:
> > I really like this idea. Currently, aggtransspace represents an
> > estimate of the transition state size provided by the aggregate
> > definition. If it
On Mon, Sep 8, 2025 at 10:08 PM Junwang Zhao wrote:
> On Mon, Sep 8, 2025 at 4:21 PM Richard Guo wrote:
> > Your patch misses one spot: the notnullattnums in
> > get_relation_notnullatts() should also be fixed. Otherwise it LGTM.
> True, attached v2 adds that missing sp
can be shown in the attached test case (thanks to
> Richard Guo). Simple fix attached.
I'm afraid this fix isn't thorough: it covers only CHECK constraints
but not NOT NULL or partitioning constraints. For example,
create table vt (a int, b int generated always as (a *
On Tue, Sep 9, 2025 at 10:18 PM Robert Haas wrote:
> On Mon, Sep 8, 2025 at 10:22 PM Richard Guo wrote:
> > One idea (not fully thought through) is that we record the calculated
> > outerjoin_relids for each outer join in its JoinPaths. (We cannot
> > store this in the
On Fri, Sep 5, 2025 at 11:50 PM Robert Haas wrote:
> Like Matheus, I think a GUC is reasonable. A significant danger here
> appears to be the possibility of a performance cliff, where queries
> are optimized very different when the ratio is 9.99 vs. 10.01, say. It
> would be nice if there were som
On Fri, Sep 5, 2025 at 11:37 PM Robert Haas wrote:
> I spent a bit of time scrolling through this today. Here are a few
> observations/review comments.
Thanks for all the comments.
> It looks as though this will create a bunch of RelOptInfo objects that
> don't end up getting used for anything o
On Fri, Sep 5, 2025 at 10:10 PM Robert Haas wrote:
> On Fri, Jun 13, 2025 at 3:42 AM Richard Guo wrote:
> > The transformation of eager aggregation is:
> >
> > GROUP BY G, AGG(A) on (R1 JOIN R2 ON J)
> > =
> > GROUP BY G, AGG(agg_A) on ((GROUP BY G1
On Mon, Sep 8, 2025 at 10:56 PM Robert Haas wrote:
> On Mon, Sep 8, 2025 at 5:51 AM Richard Guo wrote:
> > BTW, I'm wondering if we can take outer join relids into account in
> > assert_join_preserves_scan_rtis(), which could make the check more
> > useful. A joinrel&
On Sun, Sep 7, 2025 at 8:26 PM Alexander Korotkov wrote:
> Great, thank you for catching this. The diff of costs is attached. I
> see the costs now are better or within the fuzz factor.
Will have a review by the end of this commitfest.
- Richard
On Sun, Sep 7, 2025 at 8:12 PM Junwang Zhao wrote:
> While reading this thread, I found that it uses *Relids* to collect NOT NULL
> attribute numbers, I think this might be an oversight, since ISTM that
> Relids is used to represent the index of the relation in the range table.
Nice catch; it's b
On Wed, Sep 3, 2025 at 5:07 AM Robert Haas wrote:
> Thanks for the review. Responding just briefly to avoid quoting too much text:
>
> - I'm glad to hear that you like 0002 and consider it an improvement
> independent of what follows.
> - I'm glad to hear that you're OK with the current split betw
On Wed, Sep 3, 2025 at 5:41 PM Peter Eisentraut wrote:
> I have committed this with a few of the small changes mentioned nearby.
copperhead reported just now a test failure in test_oat_hooks:
SET debug_discard_caches = 0;
+ERROR: unrecognized configuration parameter "debug_discard_caches"
I'm
On Tue, Sep 2, 2025 at 7:56 PM Andrei Lepikhov wrote:
> No questions, it is good enough optimisation. I'm worried only about
> implementation: It creates one more RelOptInfo that may look like a
> baserel, but we can't find it by find_base_rel or even find_join_rel. It
> seems a little inconsisten
On Tue, Sep 2, 2025 at 5:26 AM Alexander Korotkov wrote:
> I have another idea. What if we allow MergeAppend paths only when at
> least one subpath is preordered. This trick also allow us to exclude
> MergeAppend(Sort) dominating Sort(Append). I see the regression tests
> changes now have much
On Wed, Jul 23, 2025 at 5:11 PM Álvaro Herrera wrote:
> As a very trivial test on this patch, I ran the query in your opening
> email, both with and without the patch, scaling up the size of the table
> a little bit.
> This is a really nice improvement. I think we could find queries that
> are a
On Sun, Aug 31, 2025 at 9:50 AM Alexander Korotkov wrote:
> On Sun, Aug 31, 2025 at 2:51 AM Richard Guo wrote:
> > I think it's better to push this patch sooner rather than later, as
> > multiple people have encountered the issue in different ways. I'll go
> > ah
On Sun, Aug 31, 2025 at 8:41 AM Richard Guo wrote:
> On Sun, Aug 31, 2025 at 8:12 AM Alexander Korotkov
> wrote:
> > The same patch with a bit revised comment and commit message.
> FWIW, I reported this same issue and proposed the patch last week in
> Discussion:
>
On Sun, Aug 31, 2025 at 8:12 AM Alexander Korotkov wrote:
> > The draft patch fixing this is attached. I will continue the investigation.
>
> The same patch with a bit revised comment and commit message.
FWIW, I reported this same issue and proposed the patch last week in
Discussion:
https://po
On Fri, Aug 29, 2025 at 10:39 AM Tom Lane wrote:
> Richard Guo writes:
> > I plan to push the fix to both v18 and master, if there are no
> > objections.
> Please do.
Done.
Thanks
Richard
On Fri, Aug 29, 2025 at 2:26 AM Tom Lane wrote:
> Attached are a finished version of my v3 patch for HEAD, and the
> promised adaptation of it for v18. The only surprise I ran into
> was that I had to adopt the same sort of copy-from-the-parent
> logic as you have in HEAD in create_unique_paths,
On Thu, Aug 28, 2025 at 6:42 AM Tom Lane wrote:
> This leaves us with some pretty unappetizing choices about what
> to do in v18:
>
> 1. Try to emulate the proposed HEAD fix.
>
> 2. Try to fix up the SJE patch so that it calculates relid changes
> honestly, or at least no less honestly than what h
On Wed, Aug 27, 2025 at 2:26 AM Tom Lane wrote:
> Richard Guo writes:
> > Instead of repeatedly calling make_pathkeys_for_sortclauses to detect
> > redundant expressions, I'm wondering if we could introduce a function
> > that detects whether a given expression is
On Tue, Aug 26, 2025 at 4:16 AM Tom Lane wrote:
> I wrote:
> > Yeah. I think this is an oversight in create_unique_paths(): it's
> > building an ORDER BY list without consideration for the possibility
> > that some of the entries are known to be constant. In fact, because
> > make_pathkeys_for_s
On Tue, Aug 26, 2025 at 4:16 AM Tom Lane wrote:
> Here is a patch that fixes it that way. I like this better than
> Sergey's approach because it is making the plans better not worse.
>
> There are a couple loose ends yet to be dealt with:
>
> * The fact that we now avoid duplicate unique-ificatio
On Sat, Aug 23, 2025 at 12:27 AM Sergey Soloviev
wrote:
> I would like write a test in 'join.sql', but for now it requires patches
> to easily reproduce the bug. I appreciate it if someone could find
> an easier way to reproduce the bug and write a simple test.
Nice catch! Here's a query that re
On Fri, Aug 22, 2025 at 6:46 PM Álvaro Herrera wrote:
> I'm not sure. See the definition of relation in the glossary:
> https://www.postgresql.org/docs/18/glossary.html#GLOSSARY-RELATION
>
> The generic term for all objects in a database that have a name and a
> list of attributes defined in
On Fri, Aug 22, 2025 at 6:59 PM Álvaro Herrera wrote:
> On 2025-Aug-22, Kirill Reshke wrote:
> > I am uncertain about the delineation between when we make changes and
> > when we refrain from doing so.
> I think this is natural work after 9c727360bcc7, before which
> BufferGetPage() was a macro a
On Fri, Aug 22, 2025 at 9:44 AM Chao Li wrote:
> On Aug 21, 2025, at 22:10, Kirill Reshke wrote:
> I was looking at how PostgreSQL handles VM map bits, when I noticed $subj.
> PFA small refactoring patch.
> LGTM. BufferGetPage() returns a “Page” type, and the receiving variable
> “page” is of “
On Wed, Aug 20, 2025 at 11:11 PM Nathan Bossart
wrote:
> On Wed, Aug 20, 2025 at 10:29:03AM +0900, Richard Guo wrote:
> > On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart
> > wrote:
> >> There is still an open item for this one, but it's not clear whether we are
>
On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart wrote:
> On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote:
> > I didn't observe measurable impact, but perhaps others can run more
> > representative tests and demonstrate otherwise.
> >
> > (I recall Pete
On Mon, Aug 18, 2025 at 3:07 PM Richard Guo wrote:
> Here's the updated version of the patch, which renames the macro
> IS_UNIQUEIFIED_REL to RELATION_WAS_MADE_UNIQUE, and includes some
> comment updates as well. I plan to push it soon, barring any
> objections.
Pushed.
>
On Fri, Aug 15, 2025 at 4:22 AM Matheus Alcantara
wrote:
> Debugging this query shows that all if conditions on
> setup_eager_aggregation() returns false and create_agg_clause_infos()
> and create_grouping_expr_infos() are called. The RelAggInfo->agg_useful
> is also being set to true so I would e
On Wed, Aug 13, 2025 at 11:27 AM Tom Lane wrote:
> Richard Guo writes:
> > In this patch, the only instance that doesn't follow the "unique-ify"
> > form is the macro IS_UNIQUEIFIED_REL, as dashes are not allowed in C
> > identifiers. Maybe a better alt
On Wed, Aug 13, 2025 at 1:38 AM Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > No review, but apparently "uniquify" is more widely accepted than
> > "uniqueify".
> Personally I'd write "unique-ify", seeing that neither of the forms
> without the dash are considered good English.
On Mon, Aug 4, 2025 at 11:08 AM Richard Guo wrote:
> The v5 patch does not apply anymore, and here is a new rebase. There
> are two main changes in v6:
>
> * I choose to use the check I proposed earlier to determine whether a
> relation has been unique-ified in costsize.c.
>
On Thu, Aug 7, 2025 at 6:04 PM wenhui qiu wrote:
> In light of this commit
> (https://github.com/postgres/postgres/commit/e035863c9a04beeecc254c3bfe48dab58e389e10),
> I also recommend changing the macro to a static inline function. Macros are
> harder to debug and lack type safety.
I'm incline
On Thu, Jul 24, 2025 at 12:21 PM Richard Guo wrote:
> This patch no longer applies; here's a rebased version. Nothing
> essential has changed.
Based on some off-list testing by Matheus (CC'ed), several TPC-DS
queries that used to apply eager aggregation no longer do, which
sugge
On Fri, Aug 1, 2025 at 11:58 PM Alexandra Wang
wrote:
> While reviewing the code, the following diff concerns me:
> if (joinrel->consider_parallel &&
> - save_jointype != JOIN_UNIQUE_OUTER &&
> - save_jointype != JOIN_FULL &&
> - save_jointype != JOIN_RIGHT &&
> - save_jointype != JOIN_RIGHT_AN
On Thu, Jul 31, 2025 at 9:49 PM wenhui qiu wrote:
> > This seems to be another case where the planner chooses a suboptimal
> > plan due to inaccurate cost estimates.
> Agree ,I increased some rows , set enable_hashagg to on and off ,There's no
> difference in execution time. The execution plan
On Thu, Jul 31, 2025 at 1:08 PM Richard Guo wrote:
> On Thu, Jul 31, 2025 at 10:33 AM Alexandra Wang
> wrote:
> > While looking at the code, I also had a question about the following
> > changes in costsize.c:
> >
> > --- a/src/backend/optimizer/path/costsize.c
&
On Thu, Jul 31, 2025 at 10:33 AM Alexandra Wang
wrote:
> Thanks for the patch! I applied your patch and played around with it.
Thanks for trying out this patch.
> I have a question about the following test case you added in
> subselect.sql:
> I was under the impression that we wanted Unique on
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
&
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 Tue, Jul 29, 2025 at 9:47 AM David Rowley wrote:
> You should be pushing the qual to the lowest level that it's valid to
> evaluate it at. We do this already for HAVING quals where those will
> effectively be "transferred" to the WHERE clause when it's valid to do
> so. I'd expect the same for
On Tue, Jul 29, 2025 at 6:30 AM David Rowley wrote:
> On the whole, I don't really see this as a flaw in the Memoize code.
> We've plenty of other cases in the planner that produce inferior plans
> due to lack of enough detail or accuracy of table statistics, so I'm
> not planning on rushing to lo
I ran into a query that shows a performance regression related to the
Memoize node.
create table t (a int, b int, c int);
insert into t select i%3, i, i from generate_series(1,500)i;
analyze t;
explain (analyze, costs off, timing off)
select * from t t1 join lateral
(select t2.a, t2.b, t1.a x f
For a subquery relation, currently we consider pushing down its
restriction clauses to become WHERE or HAVING quals of the subquery
itself. This transformation can potentially avoid the need to
evaluate all subquery output rows before filtering them, which may
lead to a more efficient execution pl
On Wed, Jul 23, 2025 at 5:11 PM Álvaro Herrera wrote:
> As a very trivial test on this patch, I ran the query in your opening
> email, both with and without the patch, scaling up the size of the table
> a little bit.
> This is a really nice improvement. I think we could find queries that
> are a
After pushing commit e2debb643 I noticed redis_fdw failure on crake.
+ERROR: failed to connect to Redis: 1
+CONTEXT: SQL statement "select (select count(*) from db15) +
+(select count(*) from db15_hash) +
+(select count(*) from db15_set) +
+(select count
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 turn
On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote:
> jian he 于2025年7月17日周四 07:39写道：
>> ExecEvalJsonCoercionFinish duplicate line:
>> jsestate->escontext.error_occurred = false;
>> jsestate->escontext.error_occurred = false;
> Good catch. It was introduced by this commit 231b7d67
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
On Thu, Jul 10, 2025 at 3:40 AM Tom Lane wrote:
> Now that v19 development is open, I'd like to get this work
> pushed sooner rather than later, before the patches bit-rot
> too much, and so that we can get started on follow-on work
> to remove remaining leaks. Does anyone want to review it
> fur
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 n
On Thu, May 22, 2025 at 6:07 PM Richard Guo wrote:
> So, I think it's generally safe to use incremental sort whenever
> possible. There might be some corner cases where incremental sort is
> slower than full sort, and I think it would be best to address those
> in nodeIncr
On Thu, Jul 3, 2025 at 7:06 PM Richard Guo wrote:
> This patch does not apply again, so here is a new rebase.
>
> This version also fixes an issue related to parameterized paths: if
> the RHS has LATERAL references to the LHS, unique-ification becomes
> meaningless because the RHS
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 gat
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 Thu, Apr 10, 2025 at 7:36 PM Richard Guo wrote:
> 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
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 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.
Thi
On Mon, Jun 2, 2025 at 2:31 PM jian he wrote:
> On Thu, May 29, 2025 at 11:06 AM Richard Guo wrote:
> > Yeah, ATPrepAlterColumnType does seem like a better place. But we
> > need to ensure that ATColumnChangeRequiresRewrite sees the expanded
> > version of the expression —
I've switched back to this thread and will begin by working through
the key concerns that were previously raised.
The first concern is the lack of a proof demonstrating the correctness
of this transformation. To address this, I plan to include a detailed
proof in the README, along the lines of th
On Fri, May 16, 2025 at 5:35 PM jian he wrote:
> we have used the USING expression in ATPrepAlterColumnType,
> ATColumnChangeRequiresRewrite.
> expanding it on ATPrepAlterColumnType seems to make more sense?
>
> @@ -14467,7 +14467,7 @@ ATPrepAlterColumnType(List **wqueue,
> */
>
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 4:05 PM Richard Guo wrote:
> Therefore, I'm thinking that maybe we could create a new RelOptInfo
> for the RHS rel to represent its unique-ified version, and then
> generate all worthwhile paths for it, similar to how it's done in
> create_distinct_p
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.
On Mon, May 19, 2025 at 10:21 PM Robert Haas wrote:
> On Thu, May 15, 2025 at 9:03 AM Andrei Lepikhov wrote:
> > 2. IncrementalSort is not always more effective - it depends on the
> > column's number of groups. In my experience, a non-cost-based decision
> > one day meets the problematic case, a
I came across a query where the plan includes some unnecessary Sort
nodes. Here's an example that shows the issue.
create table t(a int, b int);
insert into t select i%100, i from generate_series(1,1)i;
create index on t(a);
vacuum analyze t;
set enable_hashagg to off;
explain (costs off)
s
On Fri, May 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> I've discovered yet another way to trigger that error:
> create table vt (a int, b int generated always as (a * 2), c int);
> insert into vt values(1);
> alter table vt alter column c type bigint using b + c;
>
> ERROR: XX000: unexpected v
On Thu, May 15, 2025 at 6:50 PM Dilip Kumar wrote:
> On Thu, May 15, 2025 at 3:14 PM Fujii Masao
> wrote:
> > How about adding a check to see whether the target relation has storage,
> > using something like RELKIND_HAS_STORAGE()?
> Yeah, that makes more sense.
+1. FWIW, not long ago we fixed
On Thu, May 15, 2025 at 1:20 AM Alvaro Herrera wrote:
> On 2025-May-14, Richard Guo wrote:
> > Attached is a patch that implements this. It also renames the
> > internally used option name and updates the error message.
> LGTM.
Thanks. I've pushed this patch and backpat
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 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 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
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
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
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 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 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 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 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 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 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 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
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 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
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 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 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 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
1 - 100 of 978 matches
Mail list logo
