fujii.y...@df.mitsubishielectric.co.jp <
fujii.y...@df.mitsubishielectric.co.jp> 于2024年6月5日周三 09:26写道：
> Hi. Tender.
>
> Thank you for modification.
>
> > From: Tender Wang
> > Sent: Tuesday, June 4, 2024 7:51 PM
> > Please add more tests. Espec
Tomasz Rybak 于2024年5月31日周五 04:21写道：
> On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote:
> >
> [ cut ]
> >
> > I have rebased master and fixed a plan diff case.
>
> We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch
> at PgConf.dev Patch Review
eful or not since we can't estimate the number of times
the subplan will be called until the outer plan is generated."
git show b6002a796d
--
Tender Wang
OpenPie: https://en.openpie.com/
all about
a base rel.
Every field has a comment. I think that's already helpful for understanding
what information
we need to optimize a base rel.
--
Tender Wang
OpenPie: https://en.openpie.com/
>
> another potential incompatibilities issue:
> ALTER TABLE DROP PRIMARY KEY
>
> see:
>
> https://www.postgresql.org/message-id/202404181849.6frtmajobe27%40alvherre.pgsql
>
>
Since Alvaro has reverted all changes to not-null constraints, so will not
have potential incompatibilities issue.
--
Tender Wang
OpenPie: https://en.openpie.com/
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
to ensure the pg_upgrade behavior is sane. I intend to get
> this pushed tomorrow, if nothing ugly comes up.
>
The new patch looks good to me.
>
> CI run: https://cirrus-ci.com/build/5471117953990656
>
>
--
Tender Wang
OpenPie: https://en.openpie.com/
ull type, other types add a AT pass to tab->subcmds.
Because
not-null should be added before re-adding index, there is no right AT pass
in current AlterTablePass.
So a new AT pass ahead AT_PASS_OLD_INDEX is needed.
Another reason is that it can use ALTER TABLE frame to set not-null.
This way l
is
case.
If the standard does not specify, then it depends on each database vendor's
decision.
Some people like not-null retained, other people may like not-null removed.
I think it will be ok if people can drop not-null or add not-null back
again after dropping pk.
In Master, not-null will reset when we drop PK directly. I hope dropping pk
indirectly
is consistent with dropping PK directly.
--
Tender Wang
OpenPie: https://en.openpie.com/
+ notnull_tbl1
> + Table "public.notnull_tbl1"
> + Column | Type | Collation | Nullable | Default | Storage | Stats
> target | Description
>
> ++-+---+--+-+-+--+-
> + c0 | integer | | not null | | plain |
> |
> +
>
> this is not what we expected?
> "not null" for "c0" now should be false?
> am I missing something?
>
Yeah, now this is expected behavior.
Users can drop manually not-null of "c0" if they want, and no error
reporte.
--
Tender Wang
OpenPie: https://en.openpie.com/
call CatalogTupleUpdate.
--
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
> "Postgres is bloatware by design: it was built to house
> PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
>
[1]
https://www.postgresql.org
messages and code comments [1] .
Except those issues, @Alexander Lakhin has found
some bugs [2]
I have some concerns that whether this patch is ready to commit.
[1]
https://www.postgresql.org/message-id/CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/dbc8b96c-3cf0-d1ee-860d-0e491da20485%40gmail.com
--
Tender Wang
OpenPie: https://en.openpie.com/
| not null |
postgres=# alter table notnull_tbl1 alter c0 drop not null;
ERROR: could not find not-null constraint on column "c0", relation
"notnull_tbl1"
--
Tender Wang
OpenPie: https://en.openpie.com/
jian he 于2024年4月10日周三 14:10写道：
> On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera
> wrote:
> >
> > On 2024-Mar-29, Tender Wang wrote:
> >
> > > I think aboved case can explain what's meaning about comments in
> > > dropconstraint_internal.
> > >
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
mass inserts into indexes may be much slower
> than building indexes from scratch.
> I think both aspects need to be carefully considered. Even if we
> accept them, this needs to be documented. I think now it's too late
> for both of these. So, this should wait for v18.
>
> --
&
It has been several days since the last email. Do you have any
suggestions, please?
What I'm concerned about is that adding a new AT_PASS is good fix? Is it
a big try?
More concerned is that it can cover all ALTER TABLE cases?
Any thoughts.
--
Tender Wang
OpenPie: https://en.openpie.com/
be broken.
>
> other than that, the change in RemoveConstraintById looks sane.
>
Above comments want to say that after pk constranit dropped, if there are
tuples in
pg_constraint, that means the definition of column has not-null constraint.
So we can't
set pg_attribute.attnotnull to false.
For example:
create table t1(a int not null);
alter table t1 add constraint t1_pk primary key(a);
alter table t1 drop constraint t1_pk;
--
Tender Wang
OpenPie: https://en.openpie.com/
Alvaro Herrera 于2024年3月28日周四 17:18写道：
> On 2024-Mar-28, Tender Wang wrote:
>
> > RemoveConstraintById() should think recurse(e.g. partition table)? I'm
> not
> > sure now.
> > If we should think process recurse in RemoveConstraintById(), the
> > function
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
jian he 于2024年3月28日周四 13:18写道：
> On Wed, Mar 27, 2024 at 10:26 PM Tender Wang wrote:
> >
> > Alvaro Herrera 于2024年3月26日周二 23:25写道：
> >>
> >> On 2024-Mar-26, Tender Wang wrote:
> >>
> >> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> >
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
int if has the
tuple. if attnotnull is ture, but pg_constraint
doesn't has that tuple. Aboved error will report.
It will be confuesed for users. Because \d shows the column c0 has not
null, and we cann't insert NULL value. But it
reports errore when users drop the NOT NULL constraint.
The attached
David Rowley 于2024年3月11日周一 13:25写道：
> On Thu, 7 Mar 2024 at 22:50, David Rowley wrote:
> >
> > On Thu, 7 Mar 2024 at 15:24, Tender Wang wrote:
> > >
> > > Andrei Lepikhov 于2024年3月6日周三 11:37写道：
> > >> I think, it is a bug. Should it be fixed (
Andrei Lepikhov 于2024年3月6日周三 11:37写道：
> I think, it is a bug. Should it be fixed (and back-patched) earlier?
>
Agreed. Need David to review it as he knows this area best.
--
Tender Wang
OpenPie: https://en.openpie.com/
Andrei Lepikhov 于2024年3月5日周二 17:36写道：
> On 1/3/2024 14:18, Tender Wang wrote:
> > During debug, I learned that numeric_add doesn't have type check like
> > rangetype, so aboved query will not report "type with xxx does not
> exist".
> >
> > And I rea
://www.postgresql.org/message-id/83281eed63c74e4f940317186372abfd%40cft.ru
--
Tender Wang
OpenPie: https://en.openpie.com/
v6-0001-Fix-wrong-used-ResetExprContext-in-ExecMemoize.patch
Description: Binary data
I read Memoize code and how other node use ResetExprContext() recently.
The comments about per_tuple_memory said that :
* ecxt_per_tuple_memory is a short-term context for expression results.
* As the name suggests, it will typically be reset once per tuple,
* before we begin to evaluate
ov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> >
> > On 26/2/2024 12:44, Tender Wang wrote:
> > > Make sense. I found MemoizeState already has a MemoryContext, so
> > I used it.
> > > I update the patch.
> > This approach is better for
y thoughts? Thanks.
--
Tender Wang
OpenPie: https://en.openpie.com/
database0.log
Description: Binary data
0001-Fix-RangeType-oid-not-found-when-doing-Memoize.patch
Description: Binary data
Andrey M. Borodin 于2023年12月14日周四 17:35写道：
>
>
> > On 14 Dec 2023, at 14:28, tender wang wrote:
> >
> > Now that AND is more faster, Can we replace the '%
> SLRU_MAX_BANKLOCKS' operation in SimpleLruGetBankLock() with '& 127'
>
> unsigned int GetBa
Andrey M. Borodin 于2023年12月14日周四 17:02写道：
>
>
> > On 14 Dec 2023, at 08:12, Amul Sul wrote:
> >
> >
> > + int bankno = pageno & ctl->bank_mask;
> >
> > I am a bit uncomfortable seeing it as a mask, why can't it be simply a
> number
> > of banks (num_banks) and get the bank number through
The v8-0001 patch failed to apply in my local repo as below:
git apply v8-0001-Make-all-SLRU-buffer-sizes-configurable.patch
error: patch failed: src/backend/access/transam/multixact.c:1851
error: src/backend/access/transam/multixact.c: patch does not apply
error: patch failed:
lvaro Herrera 于2023年10月25日周三 20:13写道：
> On 2023-Oct-25, tender wang wrote:
>
> > Hi
> >Is there any conclusion to this issue?
>
> None yet. I intend to work on this at some point, hopefully soon.
>
> --
> Álvaro Herrera Postgr
Hi
Is there any conclusion to this issue?
Jehan-Guillaume de Rorthais 于2023年8月10日周四 23:03写道：
> On Thu, 3 Aug 2023 11:02:43 +0200
> Alvaro Herrera wrote:
>
> > On 2023-Aug-03, tender wang wrote:
> >
> > > I think old "sub-FK" should not be dropped, t
David Rowley 于2023年10月11日周三 15:52写道：
> On Wed, 11 Oct 2023 at 15:49, David Rowley wrote:
> > It might have been better if PartClauseInfo could also describe IS
> > NULL quals, but I feel if we do that now then it would require lots of
> > careful surgery in partprune.c to account for that.
For hash partition table, if partition key is IS NULL clause, the
condition in if in get_steps_using_prefix_recurse:
if (cur_keyno < step_lastkeyno - 1)
is not enough.
Like the decode crashed case, explain select * from hp where a = 1 and b is
null and c = 1;
prefix list just has a = 1 clause.
I
The comment /* not needed for Consts */ may be more better close to if
(!IsA(expr, Const)).
Others look good to me.
David Rowley 于2023年10月9日周一 07:28写道：
> On Sat, 7 Oct 2023 at 03:11, Sergei Glukhov
> wrote:
> > I noticed that combination of prepared statement with generic plan and
> > 'IS
Hi tom,
Do you have any comments or suggestions on this issue? Thanks.
Richard Guo 于2023年9月8日周五 14:06写道：
>
> On Fri, Sep 8, 2023 at 3:15 AM Robert Haas wrote:
>
>> The example query provided here seems rather artificial. Surely few
>> people write a join clause that references neither of
Richard Guo 于2023年9月5日周二 18:51写道：
>
> On Tue, Sep 5, 2023 at 4:52 PM tender wang wrote:
>
>>I recently run benchmark[1] on master, but I found performance problem
>> as below:
>> ...
>>
>> I debug the code and find consider_parallel_nestloop(
: 160571.476 ms
(20 rows)
tender wang 于2023年9月5日周二 16:52写道：
> Hi all,
>
>I recently run benchmark[1] on master, but I found performance problem
> as below:
>
> explain analyze select
> subq_0.c0 as c0,
> subq_0.c1 as c1,
> subq_0.c2 as c2
> from
> (se
Hi all,
I recently run benchmark[1] on master, but I found performance problem
as below:
explain analyze select
subq_0.c0 as c0,
subq_0.c1 as c1,
subq_0.c2 as c2
from
(select
ref_0.l_shipmode as c0,
sample_0.l_orderkey as c1,
sample_0.l_quantity as c2,
This thread [1] also Improving the heapgetpage function, and looks like
this thread.
[1]
https://www.postgresql.org/message-id/a9f40066-3d25-a240-4229-ec2fbe94e7a5%40yeah.net
Muhammad Malik 于2023年9月1日周五 04:04写道：
> Hi,
>
> Is there a plan to merge this patch in PG16?
>
> Thanks,
> Muhammad
>
>
I have an range partition and query below:
create table p_range(a int, b int) partition by range (a,b); create table
p_range1 partition of p_range for values from (1,1) to (3,3); create table
p_range2 partition of p_range for values from (4,4) to (6,6); explain
select * from p_range where b =2;
The foreign key still works even though partition was detached. Is this
behavior expected?
I can't find the answer in the document. If it is expected behavior ,
please ignore the bug I reported a few days ago.
tender wang 于2023年8月4日周五 17:04写道：
> Oversight the DetachPartitionFinalize(), I fo
GetParentedForeignKeyRefs(), but the
ScanKey should be conrelid field not confrelid.
I quickly test on my above solution in my env, can be solve above issue.
tender wang 于2023年8月4日周五 17:04写道：
> Oversight the DetachPartitionFinalize(), I found another bug below:
>
> postgres=# CREATE TABLE p ( id bigint PR
present in table "p".
After detach operation, r_1 is normal relation and the inherited foreign
key 'r_p_id_fkey' should be removed.
tender wang 于2023年8月3日周四 17:34写道：
> I think the code to determine that fk of a partition is inherited or not
> is not enough.
> For example, i
try to fix this problem in the attached patch.
Any thoughts.
Alvaro Herrera 于2023年8月3日周四 17:02写道：
> On 2023-Aug-03, tender wang wrote:
>
> > I think old "sub-FK" should not be dropped, that will be violates
> foreign
> > key constraint.
>
> Yea
I think old "sub-FK" should not be dropped, that will be violates foreign
key constraint. For example :
postgres=# insert into r values(1,1);
INSERT 0 1
postgres=# ALTER TABLE r DETACH PARTITION r_1;
ALTER TABLE
postgres=# delete from p_1 where id = 1;
DELETE 1
postgres=# select * from r_1;
id |
謝東霖 于2023年6月3日周六 23:21写道：
> Hello hackers
>
> Attached is my first patch for PostgreSQL, which is a simple one-liner
> that I believe can improve the code.
>
> In the "join_search_one_level" function, I noticed that the variable
> "other_rels_list" always refers to "joinrels[1]" even when the
t1 RIGHT OUTER JOIN ONLY t2 ON t2.c0 RIGHT OUTER JOIN
v0 ON ((t2.c1)=(0.08182310538090898))) as res;
ERROR: wrong varnullingrels (b 5 7) (expected (b)) for Var 3/3
regards, tender wang
Tom Lane 于2023年5月11日周四 00:32写道：
> Bharath Rupireddy writes:
> > And, the /* do not unlock till end of xact */, it looks like it's been
> > there from day 1. It may be indicating that the ref count fo the new
> > relation created in heap_create_with_catalog() will be decremented at
> > the end
Bharath Rupireddy 于2023年5月10日周三
22:17写道：
> On Sat, Mar 18, 2023 at 12:34 PM Xiaoran Wang wrote:
> >
> > Hi hackers,
> >
> > In heap_create_with_catalog, the Relation new_rel_desc is created
> > by RelationBuildLocalRelation, not table_open. So it's better to
> > call RelationClose to release
a problem if using
table_close()?
> What's more, the comment for it seems useless, just delete it.
>
> Thanks!
>
regard, tender wang
Richard Guo 于2023年4月21日周五 15:35写道：
> There was discussion in [1] about improvements to list manipulation in
> several places. But since the discussion is not related to the topic in
> that thread, fork a new thread here and attach a patch to show my
> thoughts.
>
> Some are just cosmetic
Attached file included table schema information, but no data.
tender wang 于2023年4月4日周二 10:53写道：
> Hi hackers,
> I encounter a problem, as shown below:
>
> query:
> select
> ref_0.ps_suppkey as c0,
> ref_1.c_acctbal as c1,
> ref_2.o_totalprice as c2,
>
e Filter: false
-> Hash
-> Result
One-Time Filter: false
(13 rows)
regards, tender
wang
++++
(0 rows)
tender wang 于2023年3月6日周一 22:48写道：
> Results on 16devel:
> c0 | c3 | c6 | c7 |c8
> ++++---
> 0 |||| ALGERIA
> 0 |||| ETHIOPIA
> 0 |||| KENYA
> 0 ||
tender wang
[image: 附件]14:51 (2小时前)
发送至 pgsql-hackers
Hi hackers.
This query has different result on 16devel and 15.2.
select
sample_3.n_regionkey as c0,
ref_7.l_linenumber as c3,
sample_4.l_quantity as c6,
sample_5.n_nationkey as c7,
sample_3.n_name as c8
from
ubq_0.c1
-> Result
One-Time Filter: false
(4 rows)
Attached file included table schema info.
regards, tender wang
dbt3-s0.01-janm.sql
Description: Binary data
urrent_query;
+ return result;
}
regards, tender wang
es.
With kindest regards, tender wang
64 matches
Mail list logo
