Re: add timing information to pg_upgrade

On 28.07.23 01:51, Nathan Bossart wrote: I've been looking into some options for reducing the amount of downtime required for pg_upgrade, and $SUBJECT seemed like something that would be worthwhile independent of that effort. The attached work-in-progress patch adds the elapsed time spent in eac

Re: add timing information to pg_upgrade

On 31.07.23 20:37, Nathan Bossart wrote: - prep_status("Checking for incompatible \"aclitem\" data type in user tables"); + prep_status("Checking for \"aclitem\" data type in user tables"); Why these changes? I think this is losing precision about what it's doing.

Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)

> On 24 May 2023, at 23:05, Justin Pryzby wrote: > I'm planning to set this patch as ready This is marked RfC so I'm moving this to the next CF, but the patch no longer applies so it needs a rebase. -- Daniel Gustafsson

Re: add timing information to pg_upgrade

> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: > On 28.07.23 01:51, Nathan Bossart wrote: >> This information can be used to better understand where the time is going >> and to validate future improvements. > > But who would use that, other than, you know, you, right now? > > I think the pg

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

add the missing leading `l` for log_statement_sample_rate -- Regards Junwang Zhao 0001-zh_CN.po-fix-a-typo-in-simplified-Chinese-translatio.patch Description: Binary data

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On Thu, Jul 13, 2023 at 5:08 PM Masahiko Sawada wrote: > > On Sat, Jul 8, 2023 at 11:54 AM John Naylor > wrote: > > > > > > On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada > > wrote: > > > > > > On Wed, Jul 5, 2023 at 8:21 PM John Naylor > > > wrote: > > > > Well, it's going to be a bit o

Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

> On 22 Mar 2023, at 09:17, Andrei Zubkov wrote: > New version is attached. This patch is marked RfC but didn't get reviewed/committed during this CF so I'm moving it to the next, the patch no longer applies though so please submit an updated version. -- Daniel Gustafsson

Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()

On Tue, Aug 1, 2023 at 11:33 AM Amit Kapila wrote: > > On Mon, Jul 31, 2023 at 8:46 PM Masahiko Sawada wrote: > > > > While reading the code, I realized that the following code comments > > might not be accurate: > > > > /* > > * Pick the largest transaction (or subtransaction) a

Oversight in reparameterize_path_by_child leading to executor crash

For paths of type 'T_Path', reparameterize_path_by_child just does the flat-copy but does not adjust the expressions that have lateral references. This would have problems for partitionwise-join. As an example, consider regression=# explain (costs off) select * from prt1 t1 join lateral (sel

RE: CDC/ETL system on top of logical replication with pgoutput, custom client

Hi Andres. Owh, I see the error of my way... :( By ignoring commits, and committing individual operation LSNs, I was effectively rolling back the subscription. In the previous example, if I committed the LSN of the first insert of the second transaction (LSN1-500), I was basically telling Post

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

On Fri, Jul 28, 2023 at 5:48 PM vignesh C wrote: > > Here is a patch which checks that there are no WAL records other than > CHECKPOINT_SHUTDOWN WAL record to be consumed based on the discussion > from [1]. > Few comments: = 1. Do we really need 0001 patch after the latest change prop

RE: Fix compilation warnings when CFLAGS -Og is specified

Dear Horiguchi-san, Thanks for replying! > > My gcc version is 4.8.5, and ninja is 1.10.2. > > gcc 4.8 looks very old? > > AFAIS all of those complaints are false positives and if I did this > correclty, gcc 11.3 seems to have been fixed in this regard. I switched to newer gcc (8.3, still old.

Re: Extract numeric filed in JSONB more effectively

On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: > > Hi: > > Currently if we want to extract a numeric field in jsonb, we need to use > the following expression: cast (a->>'a' as numeric). It will turn a numeric > to text first and then turn the text to numeric again. Why wouldn't you use cast(a->'a

Re: Synchronizing slots from primary to standby

On Fri, Jul 28, 2023 at 8:54 PM Bharath Rupireddy wrote: > > On Thu, Jul 27, 2023 at 10:55 AM Amit Kapila wrote: > > > > I wonder if we anyway some sort of design like this because we > > shouldn't allow to spawn as many workers as the number of databases. > > There has to be some existing or new

How to build a new grammer for pg?

Hi, I’m trying to develop a new grammar for pg, can you give me a code example to reference?

Re: How to build a new grammer for pg?

Hi, On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: > Hi, I’m trying to > develop a new grammar for pg, can +you give me a code example to reference? It's unclear to me whether you want to entirely replace the flex/bison parser with something else or just add some new bison rule. If th

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

On Mon, 31 Jul 2023 at 21:39, John Naylor wrote: > master + pg_strtoint_fastpath1.patch > latency average = 938.146 ms > latency stddev = 9.354 ms > > master + pg_strtoint_fastpath2.patch > latency average = 902.808 ms > latency stddev = 3.957 ms Thanks for checking those two on your machine. I'm

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

On Tue, 1 Aug 2023 at 13:25, Andres Freund wrote: > There's a lot of larger numbers in the file, which likely reduces the impact > some. And there's the overhead of actually inserting the rows into the table, > making the difference appear smaller than it is. It might be worth special casing the

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

Hi, > As far as I can see, PerformWalRecovery() uses LOG as elevel > [...] > On top of my mind, any solution I can think of needs to add more > information to XLogReaderState, where we'd either track the type of > error that happened close to errormsg_buf which is where these errors > are tracked,

Re: Oversight in reparameterize_path_by_child leading to executor crash

Richard Guo writes: > In this case what we need to do is to adjust the TableSampleClause to > refer to the correct child relations. We can do that with the help of > adjust_appendrel_attrs_multilevel(). One problem is that the > TableSampleClause is stored in RangeTblEntry, and it does not seem

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

On Tue, 1 Aug 2023 at 13:55, David Rowley wrote: > > I tried adding the "at least 1 digit check" by adding an else { goto > slow; } in the above code, but it seems to generate slower code than > just checking if (unlikely(ptr == s)) { goto slow; } after the loop. > That check isn't quite right, b

Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

On 7/3/23 12:25, Tristan Partin wrote: On Sat Jun 24, 2023 at 8:09 AM CDT, Joe Conway wrote: Although I have not looked yet, presumably we could have similar problems with plpython. I would like to get agreement on this approach against plperl before diving into that though. Thoughts? I don

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

On Wed, 2 Aug 2023 at 01:26, Dean Rasheed wrote: > > On Tue, 1 Aug 2023 at 13:55, David Rowley wrote: > > > > I tried adding the "at least 1 digit check" by adding an else { goto > > slow; } in the above code, but it seems to generate slower code than > > just checking if (unlikely(ptr == s)) { g

Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

On Tue Aug 1, 2023 at 8:48 AM CDT, Joe Conway wrote: On 7/3/23 12:25, Tristan Partin wrote: > On Sat Jun 24, 2023 at 8:09 AM CDT, Joe Conway wrote: >> Although I have not looked yet, presumably we could have similar >> problems with plpython. I would like to get agreement on this approach >> ag

Fix error handling in be_tls_open_server()

Hi, A static analyzer reported a possible pfree(NULL) in be_tls_open_server(). Here is a fix. Also handle an error from X509_NAME_print_ex(). AFAICS, the error "SSL certificate's distinguished name contains embedded null" could not be reached at all, because XN_FLAG_RFC2253 passed to X509_N

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Mon, Jul 31, 2023 at 5:15 PM Jeff Davis wrote: > > ERROR: role "rhaas" should not execute arbitrary code provided by > > role "jconway" > > HINT: If this should be allowed, use the TRUST command to permit it. > > +1, though I'm not sure we need an extensive trust mechanism beyond > what we alre

Re: Pgoutput not capturing the generated columns

On Tue, Aug 1, 2023, at 3:47 AM, Rajendra Kumar Dangwal wrote: > With decoderbufs and wal2json the connector is able to capture the generated > column `full_name` in above example. But with pgoutput the generated column > was not captured. wal2json materializes the generated columns before deli

Re: constants for tar header offsets

On Wed Apr 19, 2023 at 8:09 AM CDT, Robert Haas wrote: On Tue, Apr 18, 2023 at 12:56 PM Dagfinn Ilmari Mannsåker wrote: > It still has magic numbers for the sizes of the fields, should those > also be named constants? I thought about that. It's arguable, but personally, I don't think it's worth

Re: logical decoding and replication of sequences, take 2

On 8/1/23 04:59, Amit Kapila wrote: > On Mon, Jul 31, 2023 at 5:04 PM Tomas Vondra > wrote: >> >> On 7/31/23 11:25, Amit Kapila wrote: >>> ... >>> >>> Yeah, I also think this needs a review. This is a sort of new concept >>> where we don't use the LSN of the slot (for cases where copy returned

Re: There should be a way to use the force flag when restoring databases

Hi Gurjeet, I have addressed all your comments except for the tests. I have tried adding test cases but I wasn't able to do it as it's in my mind. I am not able to do things like having connections to the database and trying to force the restore, then it will complete successfully otherwise it sh

Re: add timing information to pg_upgrade

On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote: > On 31.07.23 20:37, Nathan Bossart wrote: >> -prep_status("Checking for incompatible \"aclitem\" data type in user >> tables"); >> +prep_status("Checking for \"aclitem\" data type in user tables"); > > Why these changes?

Re: POC: Extension for adding distributed tracing - pg_tracing

Hi! Thanks for the improvements! >Here's a new patch with changes from the previous discussion: >- I'm now directly storing nanoseconds duration in the span instead of the instr_time. Using the instr_time macros was a bit awkward as the durations I generate don't necessarily have a starting and en

Re: add timing information to pg_upgrade

On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote: >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: >> On 28.07.23 01:51, Nathan Bossart wrote: > >>> This information can be used to better understand where the time is going >>> and to validate future improvements. >> >> But wh

One more problem with JIT

Hi hackers, I am using pg_embedding extension for Postgres which implements HNSW index (some kind of ANN search). Search query looks something like this:     SELECT _id FROM documents ORDER BY openai <=> ARRAY[0.024466066, -0.00042, -0.0012917554,... , -0.008700027] LIMIT 1; I do not p

Re: New Table Access Methods for Multi and Single Inserts

On Sun, Jun 4, 2023 at 4:08 AM Andres Freund wrote: > > Hi, > > This patch was referenced in a discussion at pgcon, so I thought I'd give it a > look, even though Bharat said that he won't have time to drive it forward... Thanks. Finally, I started to spend time on this. Just curious - may I kno

Re: should frontend tools use syncfs() ?

On Mon, Jul 31, 2023 at 11:39:46AM -0700, Nathan Bossart wrote: > I just realized I forgot to update the --help output for these utilities. > I'll do that in the next version of the patch. Done in v3. Sorry for the noise. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From be52e

Re: How to build a new grammer for pg?

On 2023-08-01 07:58, Julien Rouhaud wrote: On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: Hi, I’m trying to develop a new grammar for pg It's unclear to me whether you want to entirely replace the flex/bison parser with something else or just add some new bison rule. Or express a

Re: New Table Access Methods for Multi and Single Inserts

On Tue, Aug 1, 2023 at 9:31 AM Bharath Rupireddy wrote: > Thanks. Finally, I started to spend time on this. Just curious - may > I know the discussion in/for which this patch is referenced? What was > the motive? Is it captured somewhere? It may not have been the only place, but we at least touc

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Mon, Jul 31, 2023 at 6:10 PM Jeff Davis wrote: > Capturing the environment is not ideal either, in my opinion. It makes > it easy to carelessly depend on a schema that others might not have > USAGE privileges on, which would then create a runtime problem for > other callers. Also, I don't think

Re: constants for tar header offsets

On Tue, Aug 1, 2023 at 11:07 AM Tristan Partin wrote: > A new API design would be great, but for right now v2 is good enough and > should be committed. It is much easier to read the code with this patch > applied. > > Marking as "Ready for Committer" since we all seem to agree that this is > bette

Re: Improve the performance of nested loop join in the case of partitioned inner table

> On 4 Jul 2023, at 14:02, David Rowley wrote: > I'm going to mark this as waiting on author in the CF app. It might be > better if you withdraw it and resubmit when you have a patch that > addresses the worst-case regression issue. Since there hasn't been any updates to this thread I am marking

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, Aug 1, 2023 at 10:42 AM Robert Haas wrote: > Now, if we don't go in the direction of resolving everything at parse > time, then I think capturing search_path is probably the next best > thing, or at least the next best thing that I've thought up so far. I'd much rather strongly encourag

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

> 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-file switch if there's an >>> agreement about that. >> >> I'm attaching an up

Re: add timing information to pg_upgrade

On Tue, Aug 1, 2023 at 9:00 AM Nathan Bossart wrote: > >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: > >> But who would use that, other than, you know, you, right now? /me raises hand Or at least, me back when I was hacking on pg_upgrade performance. This, or something like it, would have

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

On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote: > returned with feedback. Please feel free to resubmit to a future CF when > there > is a new version of the patch. Isn't the real problem here that there's no consensus on what to do? Or to put a finer point on it, that Tom seems adamantl

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

> On 1 Aug 2023, at 20:45, Robert Haas wrote: > > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote: >> returned with feedback. Please feel free to resubmit to a future CF when >> there >> is a new version of the patch. > > Isn't the real problem here that there's no consensus on what to

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

On Tue, 1 Aug 2023 at 15:01, David Rowley wrote: > > Here's a patch with an else condition when the first digit check fails. > > master + fastpath4.patch: > latency average = 1579.576 ms > latency average = 1572.716 ms > latency average = 1563.398 ms > > (appears slightly faster than fastpath3.pat

Re: POC, WIP: OR-clause support for indexes

On Mon, Jul 31, 2023 at 9:38 AM Alena Rybakina wrote: > I noticed only one thing there: when we have unsorted array values in > SOAP, the query takes longer than > when it has a sorted array. I'll double-check it just in case and write > about the results later. I would expect the B-Tree preproce

Re: How to build a new grammer for pg?

On 2023-08-01 Tu 12:50, Chapman Flack wrote: On 2023-08-01 07:58, Julien Rouhaud wrote: On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: Hi, I’m trying to develop a new grammar for pg It's unclear to me whether you want to entirely replace the flex/bison parser with something else

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

> > On 1 Aug 2023, at 20:45, Robert Haas wrote: > > > > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson > wrote: > >> returned with feedback. Please feel free to resubmit to a future CF > >> when there is a new version of the patch. > > > > Isn't the real problem here that there's no consensus

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

On Tue, Aug 1, 2023 at 3:23 PM Daniel Gustafsson wrote: > I don't disagree with that, but there is nothing preventing that discussion to > continue here or on other threads. The fact that consensus is that far away > and no patch that applies exist seems to me to indicate that a new CF entry is >

Re: How to build a new grammer for pg?

On Tue, Aug 1, 2023 at 3:45 PM Andrew Dunstan wrote: > Or to enable some language other than SQL (QUEL anyone?) > A few years ago, I got a minimal POSTQUEL working again to release as a patch for April Fools' Day, which I never did. I should dig that up somewhere :) Anyway, as far as OP's origi

Re: POC, WIP: OR-clause support for indexes

Peter, I'm very glad to hear that you're researching this! Will this include skip-scan optimizations for OR or IN predicates, or when the number of distinct values in a leading non-constant index column(s) is sufficiently small? e.g. suppose there is an ORDER BY b, and WHERE clause predicates (

Re: Partial aggregates pushdown

When it is valid to filter based on a HAVING clause predicate, it should already have been converted into a WHERE clause predicate, except in the special case of an LIMIT TO .k .. ORDER BY case where the HAVING clause predicate can be determined approximately after having found k fully qualified

Re: explain analyze rows=%.0f

> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: > >> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: >> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) > > wrote: > >> This patch was marked Returned with Feedback and then later Waiting on >> Author. And it has

Re: document the need to analyze partitioned tables

> On 13 Jul 2023, at 00:21, David Rowley wrote: > > On Wed, 25 Jan 2023 at 21:43, David Rowley wrote: >> While I agree that the majority of partitions are likely to be >> relkind='r', which you might ordinarily consider a "normal table", you >> just might change your mind when you try to INSERT

Re: Add GUC to tune glibc's malloc implementation.

> On 29 Jun 2023, at 00:31, Andres Freund wrote: > On 2023-06-28 07:26:03 +0200, Ronan Dunklau wrote: >> I see it as a way to have *some* sort of control over the malloc >> implementation we use, instead of tuning our allocations pattern on top of it >> while treating it entirely as a black box. A

Re: bug: ANALYZE progress report with inheritance tables

> On 22 Jan 2023, at 17:23, Justin Pryzby wrote: > diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c > index c86e690980e..96710b84558 100644 > ... This CF entry fails to build in the CFBot since the patch isn't attached to the email, and the CFBot can't extract inline

Re: POC, WIP: OR-clause support for indexes

Jim, On Tue, Aug 1, 2023 at 1:11 PM Finnerty, Jim wrote: > Peter, I'm very glad to hear that you're researching this! Glad to hear it! > Will this include skip-scan optimizations for OR or IN predicates, or when > the number of distinct values in a leading non-constant index column(s) is > su

Re: stats test intermittent failure

Hi, On 2023-07-31 21:03:07 +0900, Masahiko Sawada wrote: > Regarding the patch, I have a comment: > > -- Test that reuse of strategy buffers and reads of blocks into these reused > --- buffers while VACUUMing are tracked in pg_stat_io. > +-- buffers while VACUUMing are tracked in pg_stat_io. If

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 11:16 -0700, David G. Johnston wrote: > They can use ALTER FUNCTION and the existing "FROM CURRENT" > specification to get back to current behavior if desired. The current behavior is that the search_path comes from the environment each execution. FROM CURRENT saves the searc

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, Aug 1, 2023 at 2:38 PM Jeff Davis wrote: > On Tue, 2023-08-01 at 11:16 -0700, David G. Johnston wrote: > > They can use ALTER FUNCTION and the existing "FROM CURRENT" > > specification to get back to current behavior if desired. > > The current behavior is that the search_path comes from

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 13:41 -0400, Robert Haas wrote: > In functions and procedures, except for the new > BEGIN ATOMIC stuff, we just store the statements as a string and they > get parsed at execution time. ... > I think that a lot of people would like it if we moved more in the > direction of p

Re: stats test intermittent failure

Andres Freund writes: > I integrated the suggested change of the comment and tweaked it a bit > more. And finally pushed the fix. This failure was originally seen on v16 (that is, pre-fork). Shouldn't the fix be back-patched? regards, tom lane

Re: Extract numeric filed in JSONB more effectively

On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: > > > > Hi: > > > > Currently if we want to extract a numeric field in jsonb, we need to use > > the following expression: cast (a->>'a' as numeric). It will

Re: Support to define custom wait events for extensions

Hi, On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: > Thanks for committing the main patch. Latest head Ubuntu 64 bits gcc 13 64 bits ./configure --without-icu make clean make In file included from ../../src/include/pgstat.h:20, from controldata_utils.c:38: ../.

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

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 terminate the DBMS immediately? We need to differentiate between: 1. No va

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 14:47 -0700, David G. Johnston wrote: > The overall point stands, it just requires defining a similar "FROM > SESSION" to allow for explicitly specifying the current default > (missing) behavior. That sounds useful as a way to future-proof function definitions that intend to

Re: Correct the documentation for work_mem

Hi, Sorry for the delay in response and thanks for the feedback! > I've reviewed and built the documentation for the updated patch. As it stands > right now I think the documentation for this section is quite clear. Sorry, I am not understanding. What is clear? The current documentation -or- t

Re: Faster "SET search_path"

On Sat, 2023-07-29 at 21:51 -0700, Nathan Bossart wrote: > On Sat, Jul 29, 2023 at 08:59:01AM -0700, Jeff Davis wrote: > > 0001: Transform the settings in proconfig into a List for faster > > processing. This is simple and speeds up any proconfig setting. > > This looks straightforward.  It might

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

On Wed, 2 Aug 2023 at 07:38, Dean Rasheed wrote: > Running the new test on slightly older Intel hardware (i9-9900K, gcc > 11.3), I get the following: Thanks for running those tests. I've now pushed the fastpath4.patch after making a few adjustments to the header comments to mention the new stuff

Re: Support to define custom wait events for extensions

On 2023-08-02 08:38, Ranier Vilela wrote: Hi, On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: Thanks for committing the main patch. Latest head Ubuntu 64 bits gcc 13 64 bits ./configure --without-icu make clean make In file included from ../../src/include/pgstat.h:20,

Re: Support to define custom wait events for extensions

Em ter., 1 de ago. de 2023 às 21:34, Masahiro Ikeda < ikeda...@oss.nttdata.com> escreveu: > On 2023-08-02 08:38, Ranier Vilela wrote: > > Hi, > > > > On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: > >> Thanks for committing the main patch. > > > > Latest head > > Ubuntu 64 bits >

Re: Use of additional index columns in rows filtering

On Mon, Jul 24, 2023 at 11:59 AM Peter Geoghegan wrote: > > That might be true but I'm not sure what to do about that unless we > > incorporate some "robustness" measure into the costing. If every > > measure we have says one plan is better, don't we have to choose it? > > I'm mostly concerned abo

Re: Extract numeric filed in JSONB more effectively

Hi Matthias: On Wed, Aug 2, 2023 at 7:33 AM Andy Fan wrote: > > > On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent < > boekewurm+postg...@gmail.com> wrote: > >> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: >> > >> > Hi: >> > >> > Currently if we want to extract a numeric field in jsonb, we

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

On Wed, 2 Aug 2023 at 12:25, David Rowley wrote: > master @ 3845577cb > latency average = 1575.879 ms > >6.79% postgres [.] pg_strtoint32_safe > > master~1 > latency average = 1968.004 ms > > 14.28% postgres [.] pg_strtoint32_safe > > REL_16_STABLE > latency average = 173

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

On 8/1/23 5:39 AM, Amit Kapila wrote: On Fri, Jul 28, 2023 at 5:48 PM vignesh C wrote: Here is a patch which checks that there are no WAL records other than CHECKPOINT_SHUTDOWN WAL record to be consumed based on the discussion from [1]. Few comments: = 2. + if (dopt.logical_s

Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()

On Tue, Aug 1, 2023 at 2:06 PM Masahiko Sawada wrote: > > On Tue, Aug 1, 2023 at 11:33 AM Amit Kapila wrote: > > > > On Mon, Jul 31, 2023 at 8:46 PM Masahiko Sawada > > wrote: > > > > > > While reading the code, I realized that the following code comments > > > might not be accurate: > > > > >

Re: Adding a LogicalRepWorker type field

Thanks for your detailed code review. Most comments are addressed in the attached v2 patches. Details inline below: On Mon, Jul 31, 2023 at 7:55 PM Bharath Rupireddy wrote: > > On Mon, Jul 31, 2023 at 7:17 AM Peter Smith wrote: > > > > PROBLEM: > > > > IMO, deducing the worker's type by examini

Re: Documentation of psql's \df no longer matches reality

On Thu, Mar 2, 2023 at 3:34 PM Tom Lane wrote: > It seems like we should either restore "trigger" as its own > type classification, or remove it from the list of properties > you can filter on, or adjust the docs to describe "t" as a > special filter condition. I'm kind of inclined to the second

Re: Adding a LogicalRepWorker type field

On Mon, Jul 31, 2023 at 11:11 PM Amit Kapila wrote: > > +1. BTW, do we need the below functions (am_tablesync_worker(), > am_leader_apply_worker()) after this work? > static inline bool > am_tablesync_worker(void) > { > - return OidIsValid(MyLogicalRepWorker->relid); > + return isTablesyncWorker

Re: Simplify some logical replication worker type checking

On Tue, Aug 1, 2023 at 12:11 PM Alvaro Herrera wrote: > > On 2023-Aug-01, Peter Smith wrote: > > > PSA a small patch making those above-suggested changes. The 'make > > check' and TAP subscription tests are all passing OK. > > I think the code ends up more readable with this style of changes, so >

Re: Adding a LogicalRepWorker type field

On Wed, Aug 2, 2023 at 8:10 AM Peter Smith wrote: > > > The am_xxx functions are removed now in the v2-0001 patch. See [1]. > > The replacement set of macros (the ones with no arg) are not strictly > necessary, except I felt it would make the code unnecessarily verbose > if we insist to pass MyLog

Inquiry about Functionality Availability in PostgreSQL

Dear PostgreSQL Development Team, I am inquiring about the availability of certain functionalities in the standard PostgreSQL database. Could you please confirm if the following functionalities are currently available in PostgreSQL: 1. Enforcement of Security Attribute Expiry 2. Restricted Data A

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

Dear Jonathan, Thank you for reading the thread! > Can I take this a step further on the user interface and ask why the > flag would be "--include-logical-replication-slots" vs. being enabled by > default? > > Are there reasons why we wouldn't enable this feature by default on > pg_upgrade, and

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

> > add the missing leading `l` for log_statement_sample_rate > > -- > Regards > Junwang Zhao -msgstr "如果值设置为0，那么打印出所有查询,以og_statement_sample_rate为准. 如果设置为-1，那么将把这个功能特性关闭." +msgstr "如果值设置为-msgstr "如果值设置为0，那么打印出所有查询,以og_statement_sample_rate为准. 如果设置为-1，那么将把这个功能特性关闭." I think it's pretty obviously.

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

At Tue, 01 Aug 2023 15:28:54 +0900 (JST), Kyotaro Horiguchi wrote in > I thoght that the failure on a stanby results in continuing to retry > reading the next record. However, I found that there's a case where > start process stops in response to OOM [1]. I've examined the calls to MemoryContex

Re: Faster "SET search_path"

On Tue, Aug 01, 2023 at 04:59:33PM -0700, Jeff Davis wrote: > + List*pair= lfirst(lc); > + char*name= linitial(pair); > + char*value = lsecond(pair); This is definitely a nitpick, but this List of Lists business feel

Re: Faster "SET search_path"

On Mon, Jul 31, 2023 at 10:28:31PM -0700, Jeff Davis 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? > > I gave this a try and it speeds things up some more. > > There might be

Re: Faster "SET search_path"

On Wed, 2 Aug 2023 at 01:07, Nathan Bossart wrote: > On Mon, Jul 31, 2023 at 10:28:31PM -0700, Jeff Davis 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? > > > > I gave t

Re: Adding a LogicalRepWorker type field

On Mon, Jul 31, 2023 at 10:47 AM Peter Smith wrote: > > Hi hackers, > > BACKGROUND: > > The logical replication has different worker "types" (e.g. apply > leader, apply parallel, tablesync). > > They all use a common structure called LogicalRepWorker, but at times > it is necessary to know what "t

Re: Faster "SET search_path"

On Tue, 2023-08-01 at 22:07 -0700, Nathan Bossart wrote: > I wonder if this is a good enough reason to _not_ proceed with this > optimization.  At the moment, I'm on the fence about it. I was wondering the same thing. It's something that could reasonably be explained to users; it's not what I'd ca

Re: Extract numeric filed in JSONB more effectively

On Tue, Aug 1, 2023 at 12:39 PM Andy Fan wrote: > > Hi: > > Currently if we want to extract a numeric field in jsonb, we need to use > the following expression: cast (a->>'a' as numeric). It will turn a numeric > to text first and then turn the text to numeric again. See > jsonb_object_field_text

Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()

On Wed, Aug 2, 2023 at 11:21 AM Amit Kapila wrote: > > On Tue, Aug 1, 2023 at 2:06 PM Masahiko Sawada wrote: > > > > On Tue, Aug 1, 2023 at 11:33 AM Amit Kapila wrote: > > > > > > On Mon, Jul 31, 2023 at 8:46 PM Masahiko Sawada > > > wrote: > > > > > > > > While reading the code, I realized th

Re: Faster "SET search_path"

On Wed, 2023-08-02 at 01:14 -0400, Isaac Morland wrote: > I don’t think the fact that an optimization might suddenly not work > in a certain situation is a reason not to optimize. What would our > query planner look like if we took that approach? ... > Instead, we should try to find ways of makin

Re: Adding a LogicalRepWorker type field

On Wed, Aug 2, 2023 at 3:35 PM Masahiko Sawada wrote: > > On Mon, Jul 31, 2023 at 10:47 AM Peter Smith wrote: > > > > Hi hackers, > > > > BACKGROUND: > > > > The logical replication has different worker "types" (e.g. apply > > leader, apply parallel, tablesync). > > > > They all use a common stru

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

Hello, I really appreciate sharing very useful scripts and benchmarking results. On Fri, Jul 28, 2023 at 6:51 PM Ashutosh Bapat wrote: > Given that most of the developers run assert enabled builds it would > be good to bring down the degradation there while keeping the > excellent speedup in non

Re: Adding a LogicalRepWorker type field

On Wed, Aug 2, 2023 at 1:00 PM Amit Kapila wrote: > > On Wed, Aug 2, 2023 at 8:10 AM Peter Smith wrote: > > > > > > The am_xxx functions are removed now in the v2-0001 patch. See [1]. > > > > The replacement set of macros (the ones with no arg) are not strictly > > necessary, except I felt it wou