Re: initial pruning in parallel append

On Tue, Aug 8, 2023 at 12:53 AM Robert Haas wrote: > On Mon, Aug 7, 2023 at 10:25 AM Amit Langote wrote: > > Note we’re talking here about “initial” pruning that occurs during > > ExecInitNode(). Workers are only launched during ExecGather[Merge]() which > > thereafter do ExecInitNode() on thei

Re: [PATCH] Add loongarch native checksum implementation.

On Tue, Aug 8, 2023 at 10:07 AM YANG Xudong wrote: > On 2023/8/7 19:01, John Naylor wrote: > > The compilation test is found in c-compiler.m4, which still has all > > logic for CFLAGS_CRC, including saving and restoring the old CFLAGS. Can > > this also be simplified? > > Fixed the function in c

Re: Using defines for protocol characters

On 2023-Aug-07, Nathan Bossart wrote: > On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote: > > Dave Cramer writes: > >> Can we vote or whatever it takes to decide on a naming pattern that is > >> acceptable ? > > > > I'm good with Robert's proposal above. > > +1 WFM as well. -- Álvar

Re: [PoC] Reducing planning time when tables have many partitions

Hi Andrey, On Tue, Aug 8, 2023 at 8:52 AM Andrey Lepikhov wrote: > It is a positive thing to access some planner internals from the > console, of course. My point is dedicated to the structuration of an > EXPLAIN output and is caused by two reasons: > 1. I use the EXPLAIN command daily to identif

Report planning memory in EXPLAIN ANALYZE

Hi All, I have been looking at memory consumed when planning a partitionwise join [1], [2] and [3]. I am using the attached patch to measure the memory consumption. The patch has been useful to detect an increased memory consumption in other patches e.g. [4] and [5]. The patch looks useful by itsel

Re: Incorrect handling of OOM in WAL replay leading to data loss

On Tue, Aug 01, 2023 at 04:39:54PM -0700, Jeff Davis wrote: > On Tue, 2023-08-01 at 16:14 +0300, Aleksander Alekseev wrote: > > Probably I'm missing something, but if memory allocation is required > > during WAL replay and it fails, wouldn't it be a better solution to > > log the error and terminat

Re: Synchronizing slots from primary to standby

Hi, On 8/8/23 7:01 AM, shveta malik wrote: On Mon, Aug 7, 2023 at 3:17 PM Drouvot, Bertrand wrote: Hi, On 8/4/23 1:32 PM, shveta malik wrote: On Fri, Aug 4, 2023 at 2:44 PM Drouvot, Bertrand wrote: On 7/28/23 4:39 PM, Bharath Rupireddy wrote: Agreed. That is why in v10,v11 patches, we

Re: WIP: new system catalog pg_wait_event

Hi, On 8/8/23 5:05 AM, Michael Paquier wrote: On Tue, Aug 08, 2023 at 11:53:32AM +0900, Kyotaro Horiguchi wrote: As I mentioned in another thread, I'm uncertain about our stance on the class id of the wait event. If a class acts as a namespace, we should include it in the view. Otherwise, if th

Re: Fix badly generated entries in wait_event_names.txt

Hi, On 8/8/23 1:25 AM, Michael Paquier wrote: On Mon, Aug 07, 2023 at 10:34:43AM +0200, Drouvot, Bertrand wrote: fa88928470 introduced src/backend/utils/activity/wait_event_names.txt that has been auto-generated. The auto-generation had parsing errors leading to bad entries in wait_event_names.

Re: 2023-08-10 release announcement draft

Op 8/8/23 om 03:15 schreef Jonathan S. Katz: Please provide your feedback no later than August 10, 2023 0:00 AoE[1]. 'You us' should be 'You use' (2x) Erik

Re: proposal: psql: show current user in prompt

po 31. 7. 2023 v 17:46 odesílatel Jelte Fennema napsal: > On Mon, 24 Jul 2023 at 21:16, Pavel Stehule > wrote: > > I don't understand how it can be possible to do it without. I need to > process possible errors, and then I need to read and synchronize protocol. > I didn't inject > > this featur

[PATCH] update the comment in SnapshotSetCommandId

Hi, I updated the comment in 'SnapshotSetCommandId' in this patch which specifies the reason why it is not necessary to update 'curcid' of CatalogSnapshot. Best regards, xiaoran 0001-Update-the-comment-in-SnapshotSetCommandId.patch Description: 0001-Update-the-comment-in-SnapshotSetCommandId.p

Re: Synchronizing slots from primary to standby

On Mon, Aug 7, 2023 at 3:17 PM Drouvot, Bertrand wrote: > > Hi, > > On 8/4/23 1:32 PM, shveta malik wrote: > > On Fri, Aug 4, 2023 at 2:44 PM Drouvot, Bertrand > > wrote: > >> On 7/28/23 4:39 PM, Bharath Rupireddy wrote: > > >> Sorry to be late, but I gave a second thought and I wonder if we real

Re: pg_upgrade fails with in-place tablespace

Thank you for your reply. I have implemented the necessary changes in accordance with your suggestions. On Tue, Aug 08, 2023 at 09:57:00AM +0800, Michael Paquier wrote: > I don't have a good feeling about enforcing allow_in_place_tablespaces > in the connection creating the tablespace, as it can b

Re: Use of additional index columns in rows filtering

On Mon, Aug 7, 2023 at 3:18 PM Peter Geoghegan wrote: > Even my patch cannot always make SAOP clauses into index quals. There > are specific remaining gaps that I hope that your patch will still > cover. The simplest example is a similar NOT IN() inequality, like > this: > > select > ctid, * > f

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Tue, Aug 8, 2023 at 3:10 AM Andres Freund wrote: > > Hi, > > On 2023-08-07 23:05:39 +0900, Masahiko Sawada wrote: > > On Mon, Aug 7, 2023 at 3:16 PM David Rowley wrote: > > > > > > On Wed, 2 Aug 2023 at 13:35, David Rowley wrote: > > > > So, it looks like this item can be closed off. I'll ho

Re: Synchronizing slots from primary to standby

On Tue, Aug 1, 2023 at 4:52 PM shveta malik wrote: > > On Thu, Jul 27, 2023 at 12:13 PM shveta malik wrote: > > > > On Thu, Jul 27, 2023 at 10:55 AM Amit Kapila > > wrote: > > > > > > On Wed, Jul 26, 2023 at 10:31 AM shveta malik > > > wrote: > > > > > > > > On Mon, Jul 24, 2023 at 9:00 AM Am

Re: [PoC] Reducing planning time when tables have many partitions

On 7/8/2023 19:15, Ashutosh Bapat wrote: On Mon, Aug 7, 2023 at 2:21 PM Andrey Lepikhov mailto:a.lepik...@postgrespro.ru>> wrote: >> Do you think that the memory measurement patch I have shared in those threads is useful in itself? If so, I will start another proposal to address

Re: [PATCH] Add loongarch native checksum implementation.

Thanks for the comment. I have updated the patch to v3. Please have a look. On 2023/8/7 19:01, John Naylor wrote: On Fri, Jun 16, 2023 at 8:28 AM YANG Xudong > wrote: > > +# If the intrinsics are supported, sets pgac_loongarch_crc32c_intrinsics, > > +# and CFL

Re: WIP: new system catalog pg_wait_event

On Tue, Aug 08, 2023 at 11:53:32AM +0900, Kyotaro Horiguchi wrote: > As I mentioned in another thread, I'm uncertain about our stance on > the class id of the wait event. If a class acts as a namespace, we > should include it in the view. Otherwise, if the class id is just an > attribute of the wai

Re: WIP: new system catalog pg_wait_event

At Mon, 7 Aug 2023 17:11:50 +0200, "Drouvot, Bertrand" wrote in > That way I think it's flexible enough to add more code if needed in > the SRF. > > The patch also: > > - updates the doc > - works with autoconf and meson > - adds a simple test > > I'm adding a new CF entry for it. As I menti

Re: Extract numeric filed in JSONB more effectively

Hi: On Mon, Aug 7, 2023 at 7:51 PM Andy Fan wrote: > Hi Jian: > > Thanks for the review! > > compared with jsonb_numeric. I am wondering if you need a free *jb. >> elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0)); >> says there two are not the same. >> > > Thanks for pointing this ou

Re: [PATCH] [zh_CN.po] fix a typo in simplified Chinese translation file

On Wed, 2 Aug 2023 at 15:45, jian he wrote: > I think it's pretty obviously. anyway. I created an commitfest entry. > https://commitfest.postgresql.org/44/4470/ I saw that there were two CF entries for this patch. I marked one as committed and the other as withdrawn. For the future, I believe th

Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?

Hi, On 2023-08-07 19:15:41 -0700, Andres Freund wrote: > The set of free CI providers has shrunk since we chose cirrus, as have the > "free" resources provided. I started, quite incomplete as of now, wiki page at > [4]. Oops, as Thomas just noticed, I left off that link: [4] https://wiki.postgre

Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?

Hi, As some of you might have seen when running CI, cirrus-ci is restricting how much CI cycles everyone can use for free (announcement at [1]). This takes effect September 1st. This obviously has consequences both for individual users of CI as well as cfbot. The first thing I think we should d

Re: 2023-08-10 release announcement draft

On 8/7/23 9:53 PM, David Rowley wrote: On Tue, 8 Aug 2023 at 13:49, Jonathan S. Katz wrote: On 8/7/23 9:45 PM, David Rowley wrote: * Fix a performance regression when running concurrent [`COPY`](https://www.postgresql.org/docs/16/sql-copy.html) statements on a single table. I think this is

Re: pg_upgrade fails with in-place tablespace

On Wed, Aug 02, 2023 at 10:38:00PM +0800, Rui Zhao wrote: > However, when using pg_dump to back up this in-place tablespace, it > is dumped with a different path: > CREATE TABLESPACE space_test LOCATION 'pg_tblspc/' > This can be confusing because it does not match the initial path > that we creat

Re: 2023-08-10 release announcement draft

On Tue, 8 Aug 2023 at 13:49, Jonathan S. Katz wrote: > > On 8/7/23 9:45 PM, David Rowley wrote: > > >> * Fix a performance regression when running concurrent > >> [`COPY`](https://www.postgresql.org/docs/16/sql-copy.html) statements on a > >> single table. > > > > I think this is still outstanding

Re: 2023-08-10 release announcement draft

On 8/7/23 9:45 PM, David Rowley wrote: * Fix a performance regression when running concurrent [`COPY`](https://www.postgresql.org/docs/16/sql-copy.html) statements on a single table. I think this is still outstanding. A bit of work has been done for the int parsing regression but it seems ther

Re: 2023-08-10 release announcement draft

On Tue, 8 Aug 2023 at 13:15, Jonathan S. Katz wrote: > Attached is the release announcement draft for the 2023-08-10 update > release, which also includes the release of PostgreSQL 16 Beta 3. Thanks for drafting this. > * Fix a performance regression when running concurrent > [`COPY`](https://ww

2023-08-10 release announcement draft

Hi, Attached is the release announcement draft for the 2023-08-10 update release, which also includes the release of PostgreSQL 16 Beta 3. Please provide your feedback no later than August 10, 2023 0:00 AoE[1]. Thanks, Jonathan [1] https://en.wikipedia.org/wiki/Anywhere_on_Earth The Postgre

Re: Support to define custom wait events for extensions

On Tue, Aug 08, 2023 at 09:39:02AM +0900, Masahiro Ikeda wrote: > I am thinking a bit that we also need another hash where the key > is a custom string. For extensions that have no dependencies > with shared_preload_libraries, I think we need to avoid that > WaitEventExtensionNew() is called repeat

Re: Check volatile functions in ppi_clauses for memoize node

On Mon, Aug 7, 2023 at 6:19 PM David Rowley wrote: > On Fri, 4 Aug 2023 at 22:26, Richard Guo wrote: > > explain (costs off) > > select * from t t1 left join lateral > > (select t1.a as t1a, t2.a as t2a from t t2) s > > on t1.a = s.t2a + random(); > > QUERY PLAN > > ---

Re: pgbench: allow to exit immediately when any client is aborted

Hello Fabien, On Mon, 7 Aug 2023 12:17:38 +0200 (CEST) Fabien COELHO wrote: > > Hello Yugo-san, > > > I attached v2 patch including the documentation and some comments > > in the code. > > I've looked at this patch. Thank you for your review! > > I'm unclear whether it does what it says: "

Re: Support to define custom wait events for extensions

On 2023-08-08 08:54, Michael Paquier wrote: On Wed, Aug 02, 2023 at 06:34:15PM +0900, Masahiro Ikeda wrote: On 2023-08-01 12:23, Andres Freund wrote: This is why the scheme as implemented doesn't really make sense to me. It'd be much easier to use if we had a shared hashtable with the identifi

Re: Using defines for protocol characters

> On Mon, 7 Aug 2023 at 16:50, Tatsuo Ishii wrote: > >> > On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote: >> >> Dave Cramer writes: >> >>> On Mon, 7 Aug 2023 at 12:59, Robert Haas >> wrote: >> PqMsgEmptyQueryResponse or something like that seems better, if we >> want to keep

Re: Using defines for protocol characters

On Mon, 7 Aug 2023 at 16:50, Tatsuo Ishii wrote: > > On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote: > >> Dave Cramer writes: > >>> On Mon, 7 Aug 2023 at 12:59, Robert Haas > wrote: > PqMsgEmptyQueryResponse or something like that seems better, if we > want to keep the curre

Re: Support to define custom wait events for extensions

On Wed, Aug 02, 2023 at 06:34:15PM +0900, Masahiro Ikeda wrote: > On 2023-08-01 12:23, Andres Freund wrote: >> This is why the scheme as implemented doesn't really make sense to me. >> It'd be >> much easier to use if we had a shared hashtable with the identifiers >> than >> what's been merged now.

Re: cpluspluscheck vs ICU

Hi, On 2023-03-10 20:10:30 -0800, Andres Freund wrote: > On 2023-03-10 19:37:27 -0800, Andres Freund wrote: > > I just hit this once more - and I figured out a fairly easy fix: > > > > We just need a > > #ifndef U_DEFAULT_SHOW_DRAFT > > #define U_DEFAULT_SHOW_DRAFT 0 > > #endif > > before i

Re: Fix badly generated entries in wait_event_names.txt

On Mon, Aug 07, 2023 at 10:34:43AM +0200, Drouvot, Bertrand wrote: > fa88928470 introduced src/backend/utils/activity/wait_event_names.txt that has > been auto-generated. The auto-generation had parsing errors leading to bad > entries in wait_event_names.txt (when the same "WAIT_EVENT" name can be

Re: Faster "SET search_path"

On Mon, 2023-08-07 at 15:39 -0700, Nathan Bossart wrote: > 0001 and 0002 LGTM. I'll probably go ahead with 0001 soon. Simple and effective. But for 0002, I was thinking about trying to optimize so check_search_path() only gets called once at the beginning, rather than for each function invocation

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Hi, On 2023-08-07 12:57:40 +0200, Christoph Berg wrote: > Re: Thomas Munro > > Thanks for testing! Would you mind trying v8 from that thread? V7 > > had a silly bug (I accidentally deleted a 'case' label while cleaning > > some stuff up, resulting in the above error...) > > v8 worked better. It

Re: Using defines for protocol characters

> On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote: >> Dave Cramer writes: >>> On Mon, 7 Aug 2023 at 12:59, Robert Haas wrote: PqMsgEmptyQueryResponse or something like that seems better, if we want to keep the current capitalization. I'm not a huge fan of the way we vary o

Re: Using defines for protocol characters

+#ifndef _PROTOCOL_H +#define _PROTOCOL_H + +#define PQMSG_REQ_BIND 'B' +#define PQMSG_REQ_CLOSE 'C' +#define PQMSG_REQ_DESCRIBE 'D' +#define PQMSG_REQ_EXECUTE 'E' +#define PQMSG_REQ_FUNCTION_CALL 'F' +#define PQMSG_REQ_FLUSH_DATA'H' +#define

Re: Faster "SET search_path"

0001 and 0002 LGTM. 0003 is looking pretty good, too, but I think we should get some more eyes on it, given the complexity. On Mon, Aug 07, 2023 at 12:57:27PM -0700, Jeff Davis wrote: > (Aside: part of the reason set_config_option() is slow is because of > the lookup in guc_hashtab. That's slower

Re: Use of additional index columns in rows filtering

On Mon, Aug 7, 2023 at 12:34 PM Tomas Vondra wrote: > But then we call get_index_paths/build_index_path a little bit later, > and that decides to skip "lower SAOP" (which seems a bit strange, > because the column is "after" the equality, but meh). Anyway, at this > point we already decided what's

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

Hi, On 2023-08-07 14:36:48 -0700, Andres Freund wrote: > What if fast path locks entered PROCLOCK into the shared hashtable, just like > with normal locks, the first time a lock is acquired by a backend. Except that > we'd set a flag indicating the lock is a fastpath lock. When the lock is > relea

Re: Using defines for protocol characters

On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote: > Dave Cramer writes: >> On Mon, 7 Aug 2023 at 12:59, Robert Haas wrote: >>> PqMsgEmptyQueryResponse or something like that seems better, if we >>> want to keep the current capitalization. I'm not a huge fan of the way >>> we vary our capi

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

Hi, On 2023-08-07 13:05:32 -0400, Robert Haas wrote: > I would also argue that the results are actually not that great, > because once you get past 64 partitions you're right back where you > started, or maybe worse off. To me, there's nothing magical about > cases between 16 and 64 relations that

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

> > Why would the access frequency be uniform? In particular, there's a huge > variability in how long the locks need to exist > As a supporting data point, our example production workload shows a 3x difference between the most versus least frequently contended lock_manager lock: https://gitlab.co

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

Hi, On 2023-08-07 13:59:26 -0700, Matt Smiley wrote: > I have not yet written a reproducer since we see this daily in production. > I have a sketch of a few ways that I think will reproduce the behavior > we're observing, but haven't had time to implement it. > > I'm not sure if we're seeing this

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

Hi Andres, thanks for helping! Great questions, replies are inline below. On Sun, Aug 6, 2023 at 1:00 PM Andres Freund wrote: > Hm, I'm curious whether you have a way to trigger the issue outside of your > prod environment. Mainly because I'm wondering if you're potentially > hitting > the issu

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On Mon, Aug 7, 2023 at 3:48 PM Tomas Vondra wrote: > Why would the access frequency be uniform? In particular, there's a huge > variability in how long the locks need to exist - IIRC we may be keeping > locks for tables for a long time, but not for indexes. From this POV it > might be better to do

Re: Using defines for protocol characters

Dave Cramer writes: > On Mon, 7 Aug 2023 at 12:59, Robert Haas wrote: >> PqMsgEmptyQueryResponse or something like that seems better, if we >> want to keep the current capitalization. I'm not a huge fan of the way >> we vary our capitalization conventions so much all over the code base, >> but I

Re: Using defines for protocol characters

On Mon, 7 Aug 2023 at 12:59, Robert Haas wrote: > On Mon, Aug 7, 2023 at 2:25 PM Tom Lane wrote: > > +1. For ease of greppability, maybe even PQMSG_EmptyQueryResponse > > and so on? Then one grep would find both uses of the constants and > > code/docs references. Not sure if the prefix should

Re: Faster "SET search_path"

On Wed, 2023-08-02 at 01:14 -0400, Isaac Morland wrote: > > > On Sat, 2023-07-29 at 12:44 -0400, Isaac Morland wrote: > > > > Essentially, "just" observe efficiently (somehow) that no > > > > change is > > > > needed, and skip changing it? ... > Speaking as someone who uses a lot of stored proced

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On 8/7/23 21:21, Robert Haas wrote: > On Mon, Aug 7, 2023 at 3:02 PM Tomas Vondra > wrote: >>> I would also argue that the results are actually not that great, >>> because once you get past 64 partitions you're right back where you >>> started, or maybe worse off. To me, there's nothing magical

Re: Use of additional index columns in rows filtering

On 8/7/23 02:38, Peter Geoghegan wrote: > On Sun, Aug 6, 2023 at 3:28 PM Peter Geoghegan wrote: >> I decided to verify my understanding by checking what would happen >> when I ran the OR-heavy tenk1 regression test query against a >> combination of your patch, and v7 of the OR-to-SAOP transform

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

Thank you Tomas! I really appreciate your willingness to dig in here and help us out! The rest of my replies are inline below. On Thu, Aug 3, 2023 at 1:39 PM Tomas Vondra wrote: > The analysis in the linked gitlab issue is pretty amazing. I wasn't > planning to argue against the findings anywa

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On Mon, Aug 7, 2023 at 3:02 PM Tomas Vondra wrote: > > I would also argue that the results are actually not that great, > > because once you get past 64 partitions you're right back where you > > started, or maybe worse off. To me, there's nothing magical about > > cases between 16 and 64 relation

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On 8/7/23 18:56, Nathan Bossart wrote: > On Mon, Aug 07, 2023 at 12:51:24PM +0200, Tomas Vondra wrote: >> The bad news is this seems to have negative impact on cases with few >> partitions, that'd fit into 16 slots. Which is not surprising, as the >> code has to walk longer arrays, it probably affe

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On 8/7/23 19:05, Robert Haas wrote: > On Mon, Aug 7, 2023 at 6:51 AM Tomas Vondra > wrote: >> The regression appears to be consistently ~3%, and v2 aimed to improve >> that - at least for the case with just 100 rows. It even gains ~5% in a >> couple cases. It's however a bit strange v2 doesn't rea

Re: Using defines for protocol characters

On Mon, Aug 7, 2023 at 2:25 PM Tom Lane wrote: > +1. For ease of greppability, maybe even PQMSG_EmptyQueryResponse > and so on? Then one grep would find both uses of the constants and > code/docs references. Not sure if the prefix should be all-caps or > not if we go this way. PqMsgEmptyQueryR

Re: [PATCH] psql: Add tab-complete for optional view parameters

Hi all, sorry for the long delay. On Mon, Jan 09, 2023 at 04:32:09PM +0100, Jim Jones wrote: > However, an "ALTER TABLE S" does not complete the open > parenthesis "(" from "SET (", as suggested in "ALTER VIEW ". > > postgres=# ALTER VIEW w SET > Display all 187 possibilities? (y or n) > > Is i

Re: Using defines for protocol characters

On Mon, Aug 07, 2023 at 02:24:58PM -0400, Tom Lane wrote: > Robert Haas writes: >> IMHO, the correspondence between the names in the patch and the >> traditional names in the documentation could be stronger. For example, >> the documentation mentions EmptyQueryResponse and >> NegotiateProtocolVers

Re: Partial aggregates pushdown

On Mon, Jul 10, 2023 at 07:35:27AM +, fujii.y...@df.mitsubishielectric.co.jp wrote: > > > I will add a postgres_fdw option "check_partial_aggregate_support". > > > This option is false, default. > > > Only if this option is true, postgres_fdw connect to the remote server > > > and get the ver

Re: Using defines for protocol characters

Robert Haas writes: > IMHO, the correspondence between the names in the patch and the > traditional names in the documentation could be stronger. For example, > the documentation mentions EmptyQueryResponse and > NegotiateProtocolVersion, but in this patch those become > PQMSG_RESP_NEGOTIATE_PROTO

Re: Performance degradation on concurrent COPY into a single relation in PG16.

Hi, On 2023-08-07 23:05:39 +0900, Masahiko Sawada wrote: > On Mon, Aug 7, 2023 at 3:16 PM David Rowley wrote: > > > > On Wed, 2 Aug 2023 at 13:35, David Rowley wrote: > > > So, it looks like this item can be closed off. I'll hold off from > > > doing that for a few days just in case anyone else

Re: Using defines for protocol characters

On Mon, Aug 7, 2023 at 1:19 PM Dave Cramer wrote: > Any other changes required ? IMHO, the correspondence between the names in the patch and the traditional names in the documentation could be stronger. For example, the documentation mentions EmptyQueryResponse and NegotiateProtocolVersion, but i

Re: Using defines for protocol characters

On Mon, 7 Aug 2023 at 03:10, Alvaro Herrera wrote: > On 2023-Aug-07, Peter Smith wrote: > > > I guess, your patch would not be much different; you can still have > > all the nice names and assign the appropriate values to the enum > > values same as now, but using an enum you might also gain > >

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On Mon, Aug 7, 2023 at 6:51 AM Tomas Vondra wrote: > The regression appears to be consistently ~3%, and v2 aimed to improve > that - at least for the case with just 100 rows. It even gains ~5% in a > couple cases. It's however a bit strange v2 doesn't really help the two > larger cases. To me, th

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On Mon, Aug 07, 2023 at 12:51:24PM +0200, Tomas Vondra wrote: > The bad news is this seems to have negative impact on cases with few > partitions, that'd fit into 16 slots. Which is not surprising, as the > code has to walk longer arrays, it probably affects caching etc. So this > would hurt the sy

Re: generic plans and "initial" pruning

On Mon, Aug 7, 2023 at 11:44 AM Tom Lane wrote: > Right, I doubt that changing that is going to work out well. > Hash joins might have issues with it too. I thought about the case, because Hash and Hash Join are such closely intertwined nodes, but I don't see any problem there. It doesn't really

Re: initial pruning in parallel append

On Mon, Aug 7, 2023 at 10:25 AM Amit Langote wrote: > Note we’re talking here about “initial” pruning that occurs during > ExecInitNode(). Workers are only launched during ExecGather[Merge]() which > thereafter do ExecInitNode() on their copy of the the plan tree. So if we > are to pass the pr

Re: generic plans and "initial" pruning

Robert Haas writes: > Second, I wondered whether the ordering of cleanup operations could be > an issue. Right now, a node can position cleanup code before, after, > or both before and after recursing to child nodes, whereas with this > design change, the cleanup code will always be run before rec

Re: generic plans and "initial" pruning

On Thu, Aug 3, 2023 at 4:37 AM Amit Langote wrote: > Here's a patch set where the refactoring to move the ExecutorStart() > calls to be closer to GetCachedPlan() (for the call sites that use a > CachedPlan) is extracted into a separate patch, 0002. Its commit > message notes an aspect of this ref

Re: WIP: new system catalog pg_wait_event

Hi, On 8/7/23 10:23 AM, Drouvot, Bertrand wrote: Hi, On 8/4/23 5:08 PM, Tom Lane wrote: "Drouvot, Bertrand" writes: Now that fa88928470 generates automatically code and documentation related to wait events, why not exposing the wait events description through a system catalog relation? I t

Re: initial pruning in parallel append

On Mon, Aug 7, 2023 at 22:29 Tom Lane wrote: > Robert Haas writes: > > ... Second, we've generally made a > > decision up until now that we don't want to have a hard dependency on > > stable functions actually being stable. If they aren't, and for > > example you're using index expressions, your

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Mon, Aug 7, 2023 at 3:16 PM David Rowley wrote: > > On Wed, 2 Aug 2023 at 13:35, David Rowley wrote: > > So, it looks like this item can be closed off. I'll hold off from > > doing that for a few days just in case anyone else wants to give > > feedback or test themselves. > > Alright, closed.

postgres_fdw could support row comparison pushdown

Hi. postgres_fdw currently doesn't handle RowCompareExpr, which doesn't allow keyset pagination queries to be efficiently executed over sharded table. Attached patch adds handling of RowCompareExpr in deparse.c, so that we could push down conditions like WHERE (created, id) > ('2023-01-01 00:0

Re: [PATCH] Support % wildcard in extension upgrade filenames

On Tue, Aug 01, 2023 at 08:24:15PM +0200, Daniel Gustafsson wrote: > > On 28 Jun 2023, at 10:29, Daniel Gustafsson wrote: > > > >> On 31 May 2023, at 21:07, Sandro Santilli wrote: > >> On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote: > > > >>> I'm happy to bring back the control

Re: Oversight in reparameterize_path_by_child leading to executor crash

On Fri, Aug 4, 2023 at 6:08 AM Richard Guo wrote: > > On Thu, Aug 3, 2023 at 7:20 PM Ashutosh Bapat < > ashutosh.bapat@gmail.com> wrote: > >> However, if reparameterization can *not* happen at the planning time, we >> have chosen a plan which can not be realised meeting a dead end. So as long

Re: initial pruning in parallel append

Robert Haas writes: > ... Second, we've generally made a > decision up until now that we don't want to have a hard dependency on > stable functions actually being stable. If they aren't, and for > example you're using index expressions, your queries may return wrong > answers, but you won't get we

Re: initial pruning in parallel append

On Tue, Jun 27, 2023 at 9:23 AM Amit Langote wrote: > Maybe that stuff could be resurrected, though I was wondering if the > risk of the same initial pruning steps returning different results > when performed repeatedly in *one query lifetime* aren't pretty > minimal or maybe rather non-existent?

Re: Minor configure/meson cleanup

I agree that the change look good. -- Tristan Partin Neon (https://neon.tech)

Re: [PoC] Reducing planning time when tables have many partitions

On Mon, Aug 7, 2023 at 2:21 PM Andrey Lepikhov wrote: > >> Do you think that the memory measurement patch I have shared in those > threads is useful in itself? If so, I will start another proposal to > address it. > > > > For me, who is developing the planner in this thread, the memory > > measur

Re: Extract numeric filed in JSONB more effectively

Hi Jian: Thanks for the review! compared with jsonb_numeric. I am wondering if you need a free *jb. > elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0)); > says there two are not the same. > Thanks for pointing this out, I am not sure what to do right now. Basically the question is th

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

On 2023-Aug-07, tender wang wrote: > The foreign key still works even though partition was detached. Is this > behavior expected? Well, there's no reason for it not to, right? For example, if you detach a partition and then attach it again, you don't have to scan the partition on attach, because

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

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 found a

Re: [PATCH] Add loongarch native checksum implementation.

On Fri, Jun 16, 2023 at 8:28 AM YANG Xudong wrote: > > +# If the intrinsics are supported, sets pgac_loongarch_crc32c_intrinsics, > > +# and CFLAGS_CRC. > > > > +# Check if __builtin_loongarch_crcc_* intrinsics can be used > > +# with the default compiler flags. > > +# CFLAGS_CRC is set if the ext

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > Thanks for testing! Would you mind trying v8 from that thread? V7 > had a silly bug (I accidentally deleted a 'case' label while cleaning > some stuff up, resulting in the above error...) v8 worked better. It succeeded a few times (at least 12, my screen scrollback didn't catc

RE: [PoC] pg_upgrade: allow to upgrade publisher node

Dear Amit, Julien, > > > > > > > > Unless I'm missing something I don't see what prevents something to > connect > > > > using the replication protocol and issue any query or even create new > > > > replication slots? > > > > > > > > > > I think the point is that if we have any slots where we have

Re: Check volatile functions in ppi_clauses for memoize node

On Fri, 4 Aug 2023 at 22:26, Richard Guo wrote: > explain (costs off) > select * from t t1 left join lateral > (select t1.a as t1a, t2.a as t2a from t t2) s > on t1.a = s.t2a + random(); > QUERY PLAN > --- > Nested Loop Left Join >

Re: pgbench: allow to exit immediately when any client is aborted

Hello Yugo-san, I attached v2 patch including the documentation and some comments in the code. I've looked at this patch. I'm unclear whether it does what it says: "exit immediately on abort", I would expect a cold call to "exit" (with a clear message obviously) when the abort occurs. C

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Mon, Aug 7, 2023 at 1:06 PM Julien Rouhaud wrote: > > On Mon, Aug 07, 2023 at 12:42:33PM +0530, Amit Kapila wrote: > > On Mon, Aug 7, 2023 at 11:29 AM Julien Rouhaud wrote: > > > > > > Unless I'm missing something I don't see what prevents something to > > > connect > > > using the replicatio

Re: Minor configure/meson cleanup

On 07.08.23 11:18, Thomas Munro wrote: 0001: There is no point in searching -lrt and -lposix4 for fdatasync() if it's supposed to help Solaris only. They moved all the realtime stuff into the main C library at least as far back as Solaris 10/OpenSolaris. 0002: There is no point in probing -lpos

Re: Synchronizing slots from primary to standby

Hi, On 8/4/23 1:32 PM, shveta malik wrote: On Fri, Aug 4, 2023 at 2:44 PM Drouvot, Bertrand wrote: On 7/28/23 4:39 PM, Bharath Rupireddy wrote: Sorry to be late, but I gave a second thought and I wonder if we really need this design. (i.e start a logical replication background worker on th

Re: Extract numeric filed in JSONB more effectively

Hi. +Datum +jsonb_object_field_type(PG_FUNCTION_ARGS) +{ + Jsonb*jb = PG_GETARG_JSONB_P(0); + text*key = PG_GETARG_TEXT_PP(1); + Oid targetOid = PG_GETARG_OID(2); compared with jsonb_numeric. I am wondering if you need a free *jb. elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0

Minor configure/meson cleanup

0001: There is no point in searching -lrt and -lposix4 for fdatasync() if it's supposed to help Solaris only. They moved all the realtime stuff into the main C library at least as far back as Solaris 10/OpenSolaris. 0002: There is no point in probing -lposix4 for anything. That was superseded by

Re: Using defines for protocol characters

On 2023-Aug-07, Peter Smith wrote: > I guess, your patch would not be much different; you can still have > all the nice names and assign the appropriate values to the enum > values same as now, but using an enum you might also gain > type-checking in the code and also get warnings for the "switch"

  1   2   >