ble (ctid);
>
> which isn't testing what it claims to test because there's a typo in
> the table name. Patch attached.
>
Good catch.
LGTM.
--
Thanks,
Tender Wang
David G. Johnston 于2025年8月4日周一 12:33写道：
> On Sun, Jul 27, 2025 at 12:53 AM Tender Wang wrote:
>
>>
>> We can merge the two scans into one. This can reduce the time complexity
>> from 2O(n) to O(n).
>>
>
> This seems like an unusual usage of big-O notation.
e? For example:preprocess_qual_conditions().
In pull_up_sublinks_jointree_recurse(), what we want to do is to pull up
the sublinks.
--
Thanks,
Tender Wang
Tender Wang 于2025年7月27日周日 15:53写道：
> Hi,
>
> While debugging the pull-up sublink codes, I noticed the
> convert_VALUES_to_ANY().
> The function is to convert "where colX in VALUES(xxx)" into SAOP. It
> firstly scans the values_list to
> make sure no volatile fu
alue (99), while the old age value is 4,
> thus using the old value will not hit the index entry.
>
Yeah, in your case, the index is non-visible for x1. Your saying is
correct. But what if the table already has an index?
--
Thanks,
Tender Wang
ld
transactions read the old version of the tuple using an index scan for old
transactions?
Pointing to the old version is friendly if the table is often updated. This
way, we don't need to update the index tuple.
--
Thanks,
Tender Wang
dump raw parse tree again "debug_print_parse", are you ok to
> add a new option "debug_print_raw_parse"?
>
If you want to add this, I prefer to "debug_print_raw_parse". You should
also add documentation to explain this new GUC.
--
Thanks,
Tender Wang
at it
only includes Const items.
We can merge the two scans into one. This can reduce the time complexity
from 2O(n) to O(n).
Also, add a brace for better/more consistent style in the attached patch.
--
Thanks,
Tender Wang
From 0eeb7487ba5bdacd260987514cd0a77eb8c88eaa Mon Sep 17 00:00:00 2001
Fr
Tom Lane 于2025年7月20日周日 02:25写道：
> Tender Wang writes:
> > Please take a look at the attached v3 patch.
>
> This is of course not ever going to make any visible performance
> difference. Still, the code is arguably clearer like this, and
> I added some comments in hopes
.ft_conversions)
> > > Remote SQL: SELECT count(*) FROM public.conversions WHERE ((d = ANY
> > > ($1::character varying[])))
> > > (4 rows)
> > >
> > > EXECUTE s(ARRAY['1','2']);
> > > ERROR: operator does not ex
xecutor/execExprInterp.c#n5230
Good catch. It was introduced by this commit 231b7d670b21.
Add Amit to the cc list.
--
Thanks,
Tender Wang
Tender Wang 于2025年7月3日周四 17:48写道：
>
>
> Andrei Lepikhov 于2025年7月3日周四 17:23写道：
>
>> On 3/7/2025 04:02, Tender Wang wrote:
>> >
>> >
>> > Andrei Lepikhov mailto:lepi...@gmail.com>> 于2025年7
>> > 月2日周三 22:29写道：
>> >
>> >
Andrei Lepikhov 于2025年7月3日周四 17:23写道：
> On 3/7/2025 04:02, Tender Wang wrote:
> >
> >
> > Andrei Lepikhov mailto:lepi...@gmail.com>> 于2025年7
> > 月2日周三 22:29写道：
> >
> > On 30/6/2025 04:38, Tender Wang wrote:
>
Andrei Lepikhov 于2025年7月2日周三 22:29写道：
> On 30/6/2025 04:38, Tender Wang wrote:
> > Do you think it's worth doing this?
> >
> >
> > Hi all,
> >
> > I have added this patch to commitfest[1]. I'm hoping someone can review
> > it for me.
Tender Wang 于2025年4月24日周四 22:07写道：
>
>
> Tender Wang 于2025年4月14日周一 14:17写道：
>
>> Hi,
>>
>> While I debug hashjoin codes, in estimate_multivariate_bucketsize(), I
>> find that
>> the list_copy(hashclauses) below is unnecessary if we have a single
Tender Wang 于2025年5月28日周三 20:38写道：
>
>
> Alvaro Herrera 于2025年5月28日周三 20:26写道：
>
>> On 2025-May-28, Tender Wang wrote:
>>
>> > I dided the codes, in QueueFKConstraintValidation(), we add three
>> > newconstraint for the
>> > fk rel, because th
Alvaro Herrera 于2025年5月28日周三 20:26写道：
> On 2025-May-28, Tender Wang wrote:
>
> > I dided the codes, in QueueFKConstraintValidation(), we add three
> > newconstraint for the
> > fk rel, because the pk rel is partition table.
> >
> > During phase 3 of AlterT
Tender Wang 于2025年5月28日周三 18:54写道：
>
>
> Antonin Houska 于2025年5月28日周三 15:51写道：
>
>> I've come across an unexpected ERROR during validation of FK constraint
>> in PG
>> 18beta1. The same works in PG 17:
>>
>> drop table if exists fk;
>> drop
gt; the new symbols, like
>
> enum AlterDomainType
> {
> AD_AlterDefault = 'T',
> AD_DropNotNull = 'N',
> ...
>
> I would prefer that.
+1
--
Thanks,
Tender Wang
;
git bisect shows since below commit, the failure started.
commit b663b9436e7509b5e73c8c372539f067cd6e66c1
Author: Álvaro Herrera
Date: Thu Jan 23 15:54:38 2025 +0100
Allow NOT VALID foreign key constraints on partitioned tables
--
Thanks,
Tender Wang
Dean Rasheed 于2025年5月28日周三 18:26写道：
> On Mon, 26 May 2025 at 12:50, Tender Wang wrote:
> >
> >> > "it is possible for the parent to be excluded from the
> >> > plan and so all of the entries in the resultRelInfo array may be for
> >&g
RAINT cc not valid;
> ^
>
> the error message seems misleading,
> should we consider it as a bug for pg18?
> the entry point is in gram.y, following part:
>
It looks like a bug, because constraint cc is not a FOREIGN KEY constraint.
--
Thanks,
Tender Wang
Dean Rasheed 于2025年5月26日周一 18:41写道：
> On Mon, 26 May 2025 at 07:46, Tender Wang wrote:
> >
> > Hi Dean,
> >
> > "it is possible for the parent to be excluded from the
> > plan and so all of the entries in the resultRelInfo array may be for
> >
stResultRel may equal (==) to rootRelation,
> in that case, we don't need to call map_variable_attnos?
>
> + if (rootRelInfo != mtstate->resultRelInfo &&
+ rootRelInfo->ri_RelationDesc->rd_rel->relkind !=
RELKIND_PARTITIONED_TABLE &&
+ (mtstate->mt_merge_subcommands & MERGE_INSERT) != 0)
Above if already does the check.
--
Thanks,
Tender Wang
Dean Rasheed 于2025年5月26日周一 04:10写道：
> On Sun, 25 May 2025 at 13:41, Dean Rasheed
> wrote:
> >
> > On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
> > >
> > > For a partitioned table, we must pass rootResultRelInfo to
> ExecInsert(). I added the check bef
Dean Rasheed 于2025年5月26日周一 04:10写道：
> On Sun, 25 May 2025 at 13:41, Dean Rasheed
> wrote:
> >
> > On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
> > >
> > > For a partitioned table, we must pass rootResultRelInfo to
> ExecInsert(). I added the check bef
Tender Wang 于2025年5月25日周日 19:17写道：
>
>
> Álvaro Herrera 于2025年5月24日周六 17:11写道：
>
>> On 2025-May-21, Andres Freund wrote:
>>
>> > Hi,
>> >
>> > In [1] I added some verification to projection building, to check if the
>> > tupleslo
igned.
I try to pass resultRelInfo to ExecInsert, the inherited INSERTed rows are
returned by RETURNING.
But some test cases in regression failed.
--
Thanks,
Tender Wang
= (1, 1);
CREATE TABLE
CREATE TABLE
INSERT 0 2
ERROR: update or delete on table "test_1" violates foreign key constraint
"test_id_1_parent_id_2_fkey1" on table "test"
DETAIL: Key (id_1, id_2)=(1, 1) is still referenced from table "test".
> Anyway, if people have a chance to give this a look, it would be
> helpful.
>
It's midnight in my time zone. I will look at this tomorrow.
--
Thanks,
Tender Wang
Daniel Gustafsson 于2025年4月16日周三 22:20写道：
> > On 14 Apr 2025, at 15:34, Tender Wang wrote:
> >
> > Hi,
> >
> > While reading the estimate_multivariate_ndistinct(),
> > I think "If a match it found, *varinfos is
> > * updated to remove the list of
Tender Wang 于2025年4月14日周一 14:17写道：
> Hi,
>
> While I debug hashjoin codes, in estimate_multivariate_bucketsize(), I
> find that
> the list_copy(hashclauses) below is unnecessary if we have a single join
> clause.
>
> List *clauses = list_copy(hashclauses);
> ..
's not, we should fix it.
BTW, the document doesn't state the order in which the commands are
executed when users specify more than one manipulation in a single ALTER
TABLE command.
--
Thanks,
Tender Wang
Tender Wang 于2025年4月14日周一 21:34写道：
> Hi,
>
> While reading the estimate_multivariate_ndistinct(),
> I think "If a match it found, *varinfos is
> * updated to remove the list of matched varinfos"
> should be "If a match is found, *varinfos is
> * updated to
t;
if (conForm->contype != CONSTRAINT_NOTNULL)
elog(ERROR, "constraint %u is not a not-null constraint", conForm->oid);
I feel that using conForm->conname is more friendly than oid for users.
Others look good for me.
--
Thanks,
Tender Wang
Alvaro Herrera 于2025年4月16日周三 03:12写道：
> On 2025-Apr-15, Tender Wang wrote:
>
> > I thought further about the lockmode calling find_inheritance_children
> > in ATPrepAddPrimaryKey.
> > What we do here? We first get oids of children, then check the if the
> > column o
Tender Wang 于2025年4月15日周二 11:20写道：
>
>
> Tom Lane 于2025年4月15日周二 05:39写道：
>
>> Alvaro Herrera writes:
>> > On 2025-Apr-14, Tom Lane wrote:
>> >> I would not have expected that adding pg_constraint rows implies
>> >> stronger locks than what
x7ffc0e561eb0) at
postmaster.c:3580
#24 0x561cd92afeb1 in ServerLoop () at postmaster.c:1702
#25 0x561cd92af7a2 in PostmasterMain (argc=3, argv=0x561cf1cffb00) at
postmaster.c:1400
#26 0x561cd914cf06 in main (argc=3, argv=0x561cf1cffb00) at main.c:227
The alter table session do check its children not-null constraint using
lockmod=8, and the copy session do get partition_qual to lock parent using
lockmode =1.
I wonder if we have to use the same lockmode for checking children's
not-null constraint.
--
Thanks,
Tender Wang
tch for that.
--
Thanks,
Tender Wang
From 55ac0d72303b7ea431d58cbbc242dc5215e13102 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 14 Apr 2025 21:28:53 +0800
Subject: [PATCH] Fix a typo
---
src/backend/utils/adt/selfuncs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
some overhead of function calls and memory copies.
Any thoughts?
--
Thanks, Tender Wang
From d4a29af25ef276a145b46ecc16d631909fb1891a Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 14 Apr 2025 13:53:15 +0800
Subject: [PATCH] Adjust the place of list_copy() in
patterns mean the same thing.
>
OK, makes sense.
--
Thanks, Tender Wang
the second formats to the third one, e.g., using
HeapTupleIsValid.
BTW, I searched the other files, some files also have different ways to
check the validity of tuples.
But the attached patch only focuses on tablecmds.c
Any thoughts?
--
Thanks, Tender Wang
From
Alexander Korotkov 于2025年4月6日周日 19:50写道：
> On Sun, Apr 6, 2025 at 2:42 PM Tender Wang wrote:
> > Daniel Gustafsson 于2025年4月6日周日 19:23写道：
> >>
> >> > On 6 Apr 2025, at 06:02, Tender Wang wrote:
> >>
> >> > I find t
Daniel Gustafsson 于2025年4月6日周日 19:23写道：
> > On 6 Apr 2025, at 06:02, Tender Wang wrote:
>
> > I find that the postgresql.conf.sample file doesn't contain
> enable_self_join_elimination guc.
> > If this is necessary, please see the attached patch.
>
> The GUC
Hi,
I find that the postgresql.conf.sample file doesn't contain
enable_self_join_elimination guc.
If this is necessary, please see the attached patch.
--
Thanks, Tender Wang
From f27c99aebbd07d4008173492c7913749b149b540 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Sun, 6 Apr 2025 11:
Alexander Korotkov 于2025年3月25日周二 18:57写道：
> On Fri, Nov 29, 2024 at 3:39 AM Tender Wang wrote:
> > Alexander Pyhalov 于2024年11月29日周五 00:02写道：
> >>
> >> Tender Wang писал(а) 2024-10-09 10:26:
> >> > Hi,
> >> >When I de
Tom Lane 于2025年4月2日周三 23:15写道：
> Tender Wang writes:
> > So let's add CommandCounterIncrement() after calling
> StoreAttrMissingVal().
>
> Pushed with minor editorialization. I thought for a bit about whether
> the CCI call should be inside StoreAttrMissingVal; b
CommandCounterIncrement().
So let's add CommandCounterIncrement() after calling StoreAttrMissingVal().
--
Thanks, Tender Wang
From ee2bc290cab83daf0ebecf9f29cc23539ba19741 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Wed, 2 Apr 2025 09:52:22 +0800
Subject: [PATCH] Fix &quo
flow, we should use the alternative calculation method:
>
> uint16 mid = min + (max - min) / 2;
>
> This approach ensures that (max - min) does not exceed 65535, preventing
> the addition from overflowing while still correctly computing the middle
> index.
> Patch
>
> A patch implementing this fix is attached.
>
--
Thanks, Tender Wang
Etsuro Fujita 于2025年3月30日周日 18:28写道：
> Another thing I noticed is $SUBJECT: I think “if lock could not
> immediately acquired” should be “if lock could not be immediately
> acquired”. Attached is a patch for that.
>
Agree.
The patch looks good to me.
--
Thanks,
Tender Wang
ms is zero-based set containing attnums of NOT NULL
* columns.
But in get_relation_notnullatts():
rte->notnullattnums = bms_add_member(rte->notnullattnums,
i + 1);
The notnullattnums seem to be 1-based.
--
Thanks,
Tender Wang
https://www.postgresql.org/message-id/flat/CAHewXN=8aW4hd_W71F7Ua4+_w0=bppuvvtebfbf6g0nusxl...@mail.gmail.com
--
Thanks,
Tender Wang
David Rowley 于2025年3月24日周一 16:50写道：
> On Mon, 24 Mar 2025 at 19:50, Tender Wang wrote:
> >
> > David Rowley 于2025年3月24日周一 05:28写道：
> >> This is no longer true in master, so if we do something here it's only
> >> v17 and earlier.
> >
> > In
something here it's only
> v17 and earlier.
>
In the case of [1], we still have AccessShareLock on entity_2, even though
it is pruned during initial partition pruning.
This seems to contradict what you said. "This is no longer true in master"
.
[1]
https://postgr.es/m/01020195b987abd3-a008b77d-8c63-4931-80a4-be36a351c8b2-000...@eu-west-1.amazonses.com
--
Thanks,
Tender Wang
sponding value in the
> new enum) instead?
>
The below else branch has code if (tcategory == JSONTYPE_CAST). I guess
here the
second JSONTYPE_JSON may just be removed.
@Amit Langote please check out this.
--
Thanks,
Tender Wang
Richard Guo 于2025年3月3日周一 15:34写道：
> 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:
>
nt, or if
> there are other options to consider.
>
>
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 an impression about this?
--
Thanks,
Tender Wang
join2 t2 where T2.ID = 1000);
> QUERY PLAN
>
>
> Seq Scan on join1 t1 (cost=4.45..38673.19 rows=630150 width=8)
>Filter: (NOT (ANY (id = (hashed SubPlan 1).col1)))
>SubPlan 1
> -> Index Only Scan using idx_j2 on join2 t2 (cost=0.42..4.44 rows=1
> width=4)
>Index Cond: (id = 1000)
> (5 rows)
>
>
Planner now doesn't support pulling up the "NOT IN" sublink. The "NOT IN"
sublink will be transformed into SubPlan.
--
Thanks,
Tender Wang
Amit Langote 于2025年2月23日周日 16:36写道：
> On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
> > Alexander Lakhin 于2025年2月22日周六 23:00写道：
> >> 21.02.2025 05:40, Amit Langote wrote:
> >>
> >> I pushed the final piece yesterday.
> >>
> >>
&g
uneinfo created by
create_append_plan() is put into the head of global list.
So we first process it in ExecDoInitialPruning(). Then error reports
because we only contain 1 in estate->es_unpruned_relids.
--
Thanks,
Tender Wang
he code consistent
> > > across branches, and this avoids incorrect access patterns when
> > > copy-pasting this code.
> >
> > Hmm, fair point. I will backpatch-through 13.
>
> Done.
>
Thanks for pushing.
--
Thanks,
Tender Wang
andled.
>
Thanks for reviewing.
The BufferGetLSNAtomic() with this patch looks not complex. I think no
need more explanation here.
> Best regards,
> [Xuneng]
>
> The new status of this patch is: Waiting on Author
>
I change the status to Ready for commiter
--
Thanks,
Tender Wang
ded
> * because some places assume rel->tuples is valid for any baserel.
> */
>
> I wonder if this assumption still holds today. If we create an empty
> table, analyze it, and then use it in a query, the table will have
> rel->tuples set to zero and rel->rows set to one, which doesn't cause
> any issues today.
>
> [1]
> https://postgr.es/m/cambws4-ocromekmtvdh3rbmuajqaqdk0qi4k6zouvponmwz...@mail.gmail.com
>
> Thanks
> Richard
>
--
Thanks,
Tender Wang
Alexander Pyhalov 于2024年11月29日周五 00:02写道：
> Tender Wang писал(а) 2024-10-09 10:26:
> > Hi,
> >When I debug FDW join pushdown codes, I found below codes in
> > semijoin_target_ok():
> > if (bms_is_member(var->varno, innerrel->relids) &&
> >
t; There is one more in trgm.h, though it's OK as-is, as well.
> --
> Michael
>
Thanks for pushing.
--
Thanks,
Tender Wang
Andrey M. Borodin 于2024年11月15日周五 17:57写道：
>
>
> > On 15 Nov 2024, at 14:48, Tender Wang wrote:
> >
> > Hi,
> >
> > I found some inconsistent code format in gist.c.
> > See the attached.
>
> I’d suggest to combine such changes with some real co
Hi,
I found some inconsistent code format in gist.c.
See the attached.
--
Thanks,
Tender Wang
0001-Fix-some-codes-format-in-gist.c.patch
Description: Binary data
this is not in a macro.
> I've attached a patch.
>
Yeah, agree. The patch LGTM.
--
Thanks,
Tender Wang
local or shared
buffer.
If the buffer is local, then buffer < 0; it will be cast to uint32 when
passed to GetBufferDescriptor().
This may be unsafe, although no someone reports the problem.
I tweak a few codes; see the attached patch.
Any thoughts?
--
Thanks,
Tender Wang
0001-Fix-unsaf
Michael Paquier 于2024年11月7日周四 14:11写道：
> On Thu, Nov 07, 2024 at 10:57:08AM +0800, Tender Wang wrote:
> > Thanks for reviewing this. I have added it to the 2015-01 commitfest.
>
> Right. I don't quite see why this comment would apply anymore, and
> the commit you are
NULL /* size is currently bogus */, isnull);
> + values, isnull, true /* size is currently bogus */);
> ```
>
> I checked the rest of gistFormTuple() calls and also looked for other
> comments like this. There seems to be only one call like this to fix.
>
Thanks for reviewing this. I have added it to the 2015-01 commitfest.
--
Thanks,
Tender Wang
emoved together.
By the way, after commit 5edb24a, the comments in gistbuildCallback() was
removed.
So I think we can now remove the obsolete comment from gistinsert().
--
Thanks,
Tender Wang
0001-Remove-an-obsolete-comment-in-gistinsert.patch
Description: Binary data
Hi,
I found a typo in the comment of gistdoinsert() when I read the codes.
See the attached patch.
--
Thanks,
Tender Wang
From 9c614b424418d451fb375294733b0cdc3740a1b7 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 4 Nov 2024 22:28:24 +0800
Subject: [PATCH] Fix a typo in the comment of
Amit Langote 于2024年11月1日周五 15:27写道：
> Hi,
>
> On Wed, Oct 23, 2024 at 10:48 PM Tender Wang wrote:
> > I think the root cause of this thread and [1] are same. We don't use
> the Partition Key collation but column's
> > collation to fill
wise grouping is not the same as when
> enable_partitionwise_aggregate is off.
>
LGTM
--
Thanks,
Tender Wang
x27;s not
> the same as partcoll.
>
Me, too.
>
> Attached 0002 is what I came up with. One thing that's different from
> what Jian proposed is that match_expr_to_partition_keys() returns -1
>
Agree.
(expr not matched to any key) when the collation is also not matched
> instead of using a separate output parameter for that.
>
In have_partkey_equi_join()
...
if (exprs_known_equal(root, expr1, expr2, btree_opfamily))
{
Oid partcoll2 = rel1->part_scheme->partcollation[ipk];
I think we should use rel2 here, not rel1.
--
Thanks,
Tender Wang
jian he 于2024年10月29日周二 14:15写道：
> On Thu, Oct 24, 2024 at 3:01 PM Tender Wang wrote:
> >
> > I feel that it's hard only to use one struct(for example, X), which just
> calls equal(X, expr)
> > can check both the expression match and the collation match.
> >
Alvaro Herrera 于2024年10月28日周一 17:16写道：
> On 2024-Oct-27, Tender Wang wrote:
>
> > BTW, while reviewing the v2 patch, I found the parentConTup in
> > foreach(cell, fks) block
> > didn't need it anymore. We can remove the related codes.
>
> True. Done so in thi
d_att->natts of pt is 2.
It will not go into tp1 because tp1 is a partition of pt. But after
detach, the rel->rd_att->natts of tp1 is 1,
so "ERROR: invalid attribute number 2" will report.
CREATE TABLE tp1... will ignore the dropped column of parent, so the natts
of tp1 is 1, but its parent is 2.
--
Thanks,
Tender Wang
Alvaro Herrera 于2024年10月27日周日 05:47写道：
> On 2024-Oct-25, Alvaro Herrera wrote:
>
> > On 2024-Oct-25, Tender Wang wrote:
> >
> > > Thanks for reporting. I can reproduce this memory invalid access on
> HEAD.
> > > After debuging codes, I found the root c
Alvaro Herrera 于2024年10月25日周五 16:30写道：
> On 2024-Oct-25, Tender Wang wrote:
>
> > Thanks for reporting. I can reproduce this memory invalid access on HEAD.
> > After debuging codes, I found the root cause.
> > In DetachPartitionFinalize(), below code:
> > att =
e:
att = TupleDescAttr(RelationGetDescr(partRel),
attmap->attnums[conkey[i] - 1] - 1);
We should use confkey[i] -1 not conkey[i] - 1;
In this case, the length of attmap is 2, conkey= {2,3}, confkey={1,2},
attmap->attnums[conkey[1] -1] will trigger
memory invalid
i (pquery.c:1316)
> ==00:00:00:07.887 1079077==by 0x7D3431: PortalRun (pquery.c:791)
>
> Reproduced on REL_15_STABLE .. master.
>
Sorry, I can't reproduce this leak on master.
--
Thanks,
Tender Wang
QUERY PLAN
-
Seq Scan on pktable (cost=0.00..27.00 rows=7 width=32)
Filter: (x = 'Å'::text COLLATE ignore_accents)
(2 rows)
The filter expr in the two queries is different. And I debug the texteq;
the collid is also different.
So the result of the two queries is different. I don't look execute more
in details.
--
Thanks,
Tender Wang
Tender Wang 于2024年10月23日周三 21:48写道：
> Hi all,
>
> I find another issue as $SUBJECT when I work on [1].
>
When I continue to work on this, I find below issue. But I'm not sure
whether it is a bug.
postgres=# create table part_index(a text primary key) partition by list (
Amit Langote 于2024年10月24日周四 14:33写道：
> Hi,
>
> On Thu, Oct 24, 2024 at 1:46 PM Tender Wang wrote:
> > Tender Wang 于2024年10月23日周三 21:48写道：
> >>
> >> Hi all,
> >>
> >> I find another issue as $SUBJECT when I work on [1].
> >
> > W
Tender Wang 于2024年10月23日周三 21:48写道：
> Hi all,
>
>
> I think the root cause of this thread and [1] are same. We don't use the
> Partition Key collation but column's
> collation to fill the RelOptInfo partexprs field in
> set_baserel_partition_key_exprs().
>
me, I was unsure if it was the correct fix.
Until I find this thread issue, I think we should do it this way.
In the attached patch, I include this thread test and [1] test case.
I have two questions in my head:
1. Does partition pruning logic still check the collation match with this
patch.
Alvaro Herrera 于2024年10月22日周二 05:52写道：
> On 2024-Oct-21, Tender Wang wrote:
>
> > I suspect that we don't need the below if
> > statement anymore.
> > /*
> > * If the referenced side is partitioned (which we know because our
> > * parent's const
the referenced side is partitioned (which we know because our
* parent's constraint points to a different relation than ours) then
* we must, in addition to the above, create pg_constraint rows that
* point to each partition, each with its own action triggers.
*/
if (parentConForm->conrelid != conform->conrelid)
{
...
}
The above contidion is always true according to my test.
I haven't figured out an anti-case.
Any thoughts?
[1]
https://www.postgresql.org/message-id/CAHewXNkuU2V7GfgFkwd265RJ99%2BBfJueNEZhrHSk39o3thqxNA%40mail.gmail.com
--
Thanks,
Tender Wang
only need to provide its
> full definition (= include the other header file) if you actually want
> to access the struct's fields.
>
>
Yeah. There are many examples. For example as below:
in struct RelOptInfos,
/* use "struct FdwRoutine" to avoid including fdwapi.h here */
struct FdwRoutine *fdwroutine pg_node_attr(read_write_ignore);
--
Thanks,
Tender Wang
elids) will not execute due to short
circuit.
So I think we can remove the "!bms_is_member(var->varno, outerrel->relids)"
from if.
Any thoughts?
--
Thanks,
Tender Wang
0001-Remove-an-unnecessary-check-as-Var-can-only-belong-t.patch
Description: Binary data
wording might need work.
>
The indexing test case in regress failed with v4 patch.
alter table only idxpart add primary key (a); -- fail, no not-null
constraint
-ERROR: column a of table idxpart0 is not marked not null
+ERROR: column "a" of table "idxpart0" is not marked NOT NULL
It seemed the error message forgot to change.
--
Thanks,
Tender Wang
https://www.openpie.com/
his made me realize that there is a more general problem, to
> wit, that pg_dump is not dumping not-null constraint names correctly --
> sometimes they just not dumped, which is Not Good. I'll have to look
> into that once more.
>
>
> (Also: there are still a few additional test stanzas in regress/ that
> ought to be removed; also, I haven't re-tested sepgsql, so it's probably
> broken ATM.)
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
>
--
Thanks,
Tender Wang
create table cc3() inherits(pp1,cc1,cc2);
>
> alter table pp1 alter f1 set not null;
> ERROR: tuple already updated by self
>
I guess some place needs call CommandCounterIncrement().
--
Thanks,
Tender Wang
Tender Wang 于2024年9月4日周三 11:48写道：
>
>
> Richard Guo 于2024年8月21日周三 15:11写道：
>
>> On Fri, Aug 16, 2024 at 4:14 PM Richard Guo
>> wrote:
>> > I had a self-review of this patchset and made some refactoring,
>> > especially to the function that creates
*/
partially_grouped_rel->reltarget =
make_partial_grouping_target(root, grouped_rel->reltarget,
extra->havingQual);
--
Thanks,
Tender Wang
jian he 于2024年9月9日周一 16:31写道：
> On Mon, Sep 2, 2024 at 6:33 PM Tender Wang wrote:
> >
> >
> >
> > The attached patch adds List *nnconstraints, which store the not-null
> definition, in struct CreateStmt.
> > This makes me a little confused about List
Alvaro Herrera 于2024年8月8日周四 06:50写道：
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neit
ses
is_dummy_rel(). Other commiters use IS_DUMMY_REL.
3. The attached patch does not consider FDW when creating a path for
grouped_rel or grouped_join.
Do we need to think about FDW?
I haven't finished reviewing the patch set. I will continue to learn this
feature.
--
Thanks,
Tender Wang
how-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
--
Thanks,
Tender Wang
1 - 100 of 189 matches
Mail list logo
