Re: Use virtual tuple slot for Unique node

On Sat, 23 Sept 2023 at 03:15, Heikki Linnakangas wrote: > So not a win in this case. Could you peek at the outer slot type, and > use the same kind of slot for the Unique's result? Or some more > complicated logic, like use a virtual slot if all the values are > pass-by-val? I'd also like to keep

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

On Thu, Sep 21, 2023 at 11:45:06AM +0800, Bowen Shi wrote: > First I encountered the problem " FATAL: could not find > recovery.signal or standby.signal when recovering with backup_label ", > then I deleted the backup_label file and started the instance > successfully. Doing that is equal to corr

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

Hello Ashutosh and Andrey, On Wed, Sep 20, 2023 at 8:03 PM Ashutosh Bapat wrote: > While working on RestrictInfo translations patch I was thinking on > these lines. [1] uses hash table for storing translated RestrictInfo. > An EC can have a hash table to store ec_member translations. The same > p

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

On Wed, 27 Sept 2023 at 06:10, Ranier Vilela wrote: > As suggested, casting is the best option that does not add any overhead and > improves the robustness of the find_base_rel function. > I propose patch v1, with the additional addition of fixing the > find_base_rel_ignore_join function, > whic

Re: Move global variables of pgoutput to plugin private scope.

On Wed, Sep 27, 2023 at 10:51:52AM +0530, Amit Kapila wrote: > I have briefly looked at > v2-0002-Move-in_streaming-to-output-private-data in the same email [1] > but didn't think about it in detail (like whether there is any live > bug that can be fixed or is just an improvement). This looks like

Re: make add_paths_to_append_rel aware of startup cost

On Mon, 18 Sept 2023 at 22:55, Andy Fan wrote: > Here is an updated version to show what's in my mind. My current thoughts on this are that the fractional cost part adds quite a bit more complexity than the minimalistic approach of just also considering the cheapest startup path. There's also qu

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: > Attached patch adjusts pgstat_track_activity_query_size to be of > size_t from int and fixes the issue. This cannot be backpatched, and using size_t is not really needed as track_activity_query_size is capped at 1MB. Why don't you ju

Re: logfmt and application_context

> On 26 Sep 2023, at 09:56, Étienne BERSAC wrote: > Le mardi 05 septembre 2023 à 11:35 +0200, Daniel Gustafsson a écrit : >>> On 30 Aug 2023, at 14:36, Étienne BERSAC wrote: >> >>> ..what do you think of having logfmt output along json and CSV ? >> >> Less ideal is >> that there is no official

Re: [PATCH] Add inline comments to the pg_hba_file_rules view

> On 26 Sep 2023, at 20:40, Jim Jones wrote: > Do you think that this feature is in general not a good idea? I wouldn't rule it out as a bad idea per se. As always when dealing with access rules and pg_hba there is a security angle to consider, but I think that could be addressed. > Or perhaps

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On Wed, Sep 27, 2023 at 10:08 AM Michael Paquier wrote: > > On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: > > Attached patch adjusts pgstat_track_activity_query_size to be of > > size_t from int and fixes the issue. > > This cannot be backpatched, and using size_t is not really nee

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

Hi Ashutosh, On Thu, Sep 21, 2023 at 1:20 PM Ashutosh Bapat wrote: > On Thu, Sep 21, 2023 at 6:37 AM Amit Langote wrote: > > On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat > > wrote: > > > On Wed, Sep 20, 2023 at 5:24 PM Amit Langote > > > wrote: > > > > Just one comment on 0003: > > > > > >

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

On 9/26/23 23:50, Tom Lane wrote: > Tomas Vondra writes: >> Hmmm, I got to install BETA2 yesterday, but I still se the tcl failure: > > Huh. I'm baffled as to what's up there. Is it possible that this is > actually a hardware-based difference? I didn't think there was much > difference betwe

Re: Synchronizing slots from primary to standby

Hi, On 9/19/23 6:50 AM, shveta malik wrote: On Wed, Sep 13, 2023 at 5:19 PM Amit Kapila wrote: On Wed, Sep 13, 2023 at 4:54 PM shveta malik wrote: PFA v17. It has below changes: @@ -2498,6 +2500,13 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, ReorderBufferTXN *txn, } else { +

Re: pg_upgrade and logical replication

On Tue, 26 Sept 2023 at 10:58, vignesh C wrote: > > On Wed, 20 Sept 2023 at 16:54, Amit Kapila wrote: > > > > On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote: > > > > > > The attached v8 version patch has the changes for the same. > > > > > > > Is the check to ensure remote_lsn is valid correct

Re: Index AmInsert Parameter Confused?

On Wed, 27 Sept 2023 at 05:03, jacktby jacktby wrote: > > > > > 2023年9月27日 00:45，Matthias van de Meent 写道： > > > > On Tue, 26 Sept 2023 at 18:38, jacktby jacktby wrote: > >> > >> typedef bool (*aminsert_function) (Relation indexRelation, > >> Datum *values, > >> bool *isnull, > >> ItemPointer

Re: ubsan

Hello Andres, 22.11.2022 02:15, Andres Freund wrote: Hi, On 2022-09-29 18:17:55 -0700, Andres Freund wrote: Attached is a rebased version of this patch. Hopefully with a reasonable amount of comments? I kind of wanted to add a comment to reached_main, but it just seems to end up restating the

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote: > > Here are some comments. Thanks for your review. > > Please merge 0003 into 0002. Done. > > + /* > +* But the list of operator OIDs and the list of expressions may be > +* referenced somewhere else. Do not free those. > +*/ >

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Wed, Sep 27, 2023 at 8:07 PM Ashutosh Bapat wrote: > On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote: > > Just out of curiosity, is their not being present in join_info_list > > problematic in some manner, such as missed optimization opportunities > > for child joins? I noticed there is a

Re: logfmt and application_context

Hi, Le mercredi 27 septembre 2023 à 10:14 +0200, Daniel Gustafsson a écrit : > Being a common format in ingestion tools makes it interesting though, but I > wonder if those tools aren't alreday supporting CSV such that adding logfmt > won't move the compatibility markers much? Compared to CSV, lo

Re: Synchronizing slots from primary to standby

On Mon, Sep 25, 2023 at 7:46 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Ajin, Shveta, > > Thank you for rebasing the patch set! Here are new comments for v19_2-0001. > Thank You Kuroda-san for the feedback. Most of these are addressed in v20. Please find my response inline. > 01. WalSndWaitForSt

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал 2023-09-27 01:35: Hi Mr.Momjian, Mr.Pyhalov. Tuesday, 26 September 2023 22:15 Alexander Pyhalov : Do you mean that extra->partial_target->sortgrouprefs is not replaced, and so we preserve tlesortgroupref numbers? Yes, that is correct. I'm suspici

Re: Testing autovacuum wraparound (including failsafe)

Sorry for the late reply. On Sun, Sep 3, 2023 at 2:48 PM Noah Misch wrote: > > On Wed, Jul 12, 2023 at 01:47:51PM +0200, Daniel Gustafsson wrote: > > > On 12 Jul 2023, at 09:52, Masahiko Sawada wrote: > > > Agreed. The timeout can be set by manually setting > > > PG_TEST_TIMEOUT_DEFAULT, but I b

Re: should frontend tools use syncfs() ?

On 17.08.23 04:50, Michael Paquier wrote: Yeah, this crossed my mind. Do you know of any existing examples of options with links to a common section? One problem with this approach is that there are small differences in the wording for some of the frontend utilities, so it might be difficult to

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Karl, Thank you for reviewing! > A related thing that's nice to have is to limit the line > length of the documentation source to 80 characters or less. > 79 is probably best. Since the source text around your patch > conforms to this convention you should also. IIUC it is not hard limit,

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Peter, Thank you for reviewing! > > TBH, I felt the new text descriptions deviated a bit too much from the > originals. IMO only quite a small tweak was needed, so my suggested > text in the comments below reflects that. Good point, my patch may be too much. > Commit message. > > 1. > mi

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Tom, > No, I'm pretty sure you're mistaken. It's been a long time since > high school English, but the way I think this works is that "that" > introduces a restrictive clause, which narrows the scope of what > you are saying. That is, you say "that" when you want to talk > about only the by

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

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 the

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

Em qua., 27 de set. de 2023 às 04:35, David Rowley escreveu: > On Wed, 27 Sept 2023 at 06:10, Ranier Vilela wrote: > > As suggested, casting is the best option that does not add any overhead > and improves the robustness of the find_base_rel function. > > I propose patch v1, with the additional

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

Tomas Vondra writes: > On 9/26/23 23:50, Tom Lane wrote: >> Huh. I'm baffled as to what's up there. Is it possible that this is >> actually a hardware-based difference? I didn't think there was much >> difference between Pi 3B and Pi 4, but we're running out of other >> explanations. > Hmm, ye

Re: pg_upgrade and logical replication

On Wed, Sep 27, 2023 at 3:37 PM vignesh C wrote: > > On Tue, 26 Sept 2023 at 10:58, vignesh C wrote: > > > > On Wed, 20 Sept 2023 at 16:54, Amit Kapila wrote: > > > > > > On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote: > > > > > > > > The attached v8 version patch has the changes for the same.

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

At 2023-09-27 10:37:45 -0300, ranier...@gmail.com wrote: > > Forgive my impulsiveness, anyone who loves perfect, well written code, > would understand. I actually find this characterisation offensive. Being scrupulous about not grouping random drive-by changes together with the primary change is

Re: remaining sql/json patches

Op 9/27/23 om 15:55 schreef Amit Langote: On Thu, Sep 21, 2023 at 9:41 PM Amit Langote wrote: I don't knoe, maybe it's worthwhile to fix this (admittedly trivial) fail in the tests? It's been there for a while. Thanks, Erik diff -U3 /home/aardvark/pg_stuff/pg_sandbox/pgsql.json_table/src

Re: Is this a problem in GenericXLogFinish()?

On Tue, Sep 26, 2023 at 9:36 PM Jeff Davis wrote: > That site is pretty trivial to fix, but there are also a couple places > in hash.c and hashovfl.c that are registering a clean page and it's not > clear to me exactly what's going on. Huh, I wonder if that's just a bug. Do you know where exactly

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On 27.09.23 09:08, Michael Paquier wrote: On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: Attached patch adjusts pgstat_track_activity_query_size to be of size_t from int and fixes the issue. This cannot be backpatched, and using size_t is not really needed as track_activity_quer

Re: Is this a problem in GenericXLogFinish()?

On Wed, 2023-09-27 at 10:36 -0400, Robert Haas wrote: > On Tue, Sep 26, 2023 at 9:36 PM Jeff Davis wrote: > > That site is pretty trivial to fix, but there are also a couple > > places > > in hash.c and hashovfl.c that are registering a clean page and it's > > not > > clear to me exactly what's go

Re: SLRUs in the main buffer pool - Page Header definitions

On Fri, Sep 8, 2023 at 8:56 AM Stephen Frost wrote: > If we're going to effectively segregate the buffer pool into SLRU parts > vs. everything else and then use the existing strategies for SLRUs and > have that be different from what everything else is using ... then > that doesn't seem like it's

Re: Is this a problem in GenericXLogFinish()?

On Wed, Sep 27, 2023 at 11:03 AM Jeff Davis wrote: > So it looks like it's intentionally registering a clean buffer so that > it can take a cleanup lock for reasons other than cleaning (or even > modiying) the page. I would think that there's a better way of > accomplishing that goal, so perhaps w

Re: Is this a problem in GenericXLogFinish()?

On 27/09/2023 18:47, Robert Haas wrote: On Wed, Sep 27, 2023 at 11:03 AM Jeff Davis wrote: So it looks like it's intentionally registering a clean buffer so that it can take a cleanup lock for reasons other than cleaning (or even modiying) the page. I would think that there's a better way of ac

Re: Index AmInsert Parameter Confused?

> 2023年9月27日 18:08，Matthias van de Meent 写道： > > On Wed, 27 Sept 2023 at 05:03, jacktby jacktby > wrote: >> >> >> >>> 2023年9月27日 00:45，Matthias van de Meent 写道： >>> >>> On Tue, 26 Sept 2023 at 18:38, jacktby jacktby wrote: typedef bool (*aminsert_func

Re: Eager page freeze criteria clarification

Hi, (I wrote the first part of the email before Robert and I chatted on a call, I left it in the email for posterity) On 2023-09-26 13:49:32 -0400, Robert Haas wrote: > On Tue, Sep 26, 2023 at 11:11 AM Andres Freund wrote: > > As long as the most extreme cases are prevented, unnecessarily freezi

Set enable_seqscan doesn't take effect?

postgres=# SET enable_seqscan = off; SET postgres=# explain select * from t; QUERY PLAN - Seq Scan on t (cost=100.00..123.60 rows=1360 width=32) (

Re: Index range search optimization

On Mon, Sep 25, 2023 at 1:18 PM Alexander Korotkov wrote: > On Mon, Sep 25, 2023 at 12:58 PM Pavel Borisov > wrote: > > One more doubt about naming. Calling function > > _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts, > > ScanDirection dir, bool *continuescan, bool requiredMatc

Re: Unlinking Parallel Hash Join inner batch files sooner

On 11/05/2023 00:00, Jehan-Guillaume de Rorthais wrote: On Wed, 10 May 2023 15:11:20 +1200 Thomas Munro wrote: The reason I didn't do this earlier is that sharedtuplestore.c continues the pre-existing tradition where each parallel process counts what it writes against its own temp_file_limit.

Re: Eager page freeze criteria clarification

Hi, On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > On Tue, Sep 26, 2023 at 8:19 AM Andres Freund wrote: > > However, I'm not at all convinced doing this on a system wide level is a > > good > > idea. Databases do often contain multiple types of workloads at the same > > time. E.g., we wa

Re: Set enable_seqscan doesn't take effect?

Hi, On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: > postgres=# SET enable_seqscan = off; > SET > postgres=# explain select * from t; >QUERY PLAN > - > Seq

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Wed, 27 Sep 2023 12:58:54 + "Hayato Kuroda (Fujitsu)" wrote: > > Should the committer be interested, your patch applies cleanly > > and the docs build as expected. > > Yeah, but cfbot accepted previous version. Did you have anything in > your mind? No. I'm letting the committer know e

Re: Add pg_basetype() function to obtain a DOMAIN base type

Hi, Steve! On Tue, Sep 19, 2023 at 8:36 PM Steve Chavez wrote: > > Just to give a data point for the need of this function: > > https://dba.stackexchange.com/questions/231879/how-to-get-the-basetype-of-a-domain-in-pg-type > > This is also a common use case for services/extensions that require pos

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 10:01 AM Andres Freund wrote: > On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > I don't think doing this on a system wide basis with a metric like #unfrozen > pages is a good idea. It's quite common to have short lived data in some > tables while also having long-liv

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

Hi, On 2023-09-27 15:42:15 +0100, Peter Eisentraut wrote: > On 27.09.23 09:08, Michael Paquier wrote: > > On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: > > > Attached patch adjusts pgstat_track_activity_query_size to be of > > > size_t from int and fixes the issue. > > > > This ca

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 10:25:00 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 10:01 AM Andres Freund wrote: > > On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > > I don't think doing this on a system wide basis with a metric like #unfrozen > > pages is a good idea. It's quite common to

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

On 9/27/23 15:38, Tom Lane wrote: > Tomas Vondra writes: >> On 9/26/23 23:50, Tom Lane wrote: >>> Huh. I'm baffled as to what's up there. Is it possible that this is >>> actually a hardware-based difference? I didn't think there was much >>> difference between Pi 3B and Pi 4, but we're running

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 10:46 AM Andres Freund wrote: > I don't disagree that we should do something in that direction - I just don't > see the raw number of unfrozen pages being useful in that regard. If you have > a database where no pages live long, we don't need to freeze > oppportunistically,

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 12:45 PM Robert Haas wrote: > > One big sticking point for me (brought up elsewhere in this thread, but, > > AFAICT never resolved) is that it seems like the fact that we mark pages > > all-visible even when not freezing them means that no matter what > > heuristic we use,

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 15:45:06 -0400, Robert Haas wrote: > > One big sticking point for me (brought up elsewhere in this thread, but, > > AFAICT never resolved) is that it seems like the fact that we mark pages > > all-visible even when not freezing them means that no matter what > > heuristic we use,

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 11:36 AM Melanie Plageman wrote: > One big sticking point for me (brought up elsewhere in this thread, but, > AFAICT never resolved) is that it seems like the fact that we mark pages > all-visible even when not freezing them means that no matter what > heuristic we use, we

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 2:36 PM Melanie Plageman wrote: > It seems like the ideal freeze pattern for an insert-only table would be > to freeze as soon as the page is full before any checkpoints which could > force you to emit an FPI. Yes. So imagine we have two freeze criteria: 1. Do not ever op

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > What do you mean with "always freeze aggressively" - do you mean 'aggressive' > autovacuums? Or opportunistic freezing being aggressive? I don't know why the > former would be the case? I meant the latter. > > When it grows large enough, we

Re: Streaming I/O, vectored I/O (WIP)

Hi, On 2023-09-27 21:33:15 +0300, Heikki Linnakangas wrote: > I'm a bit disappointed and surprised by > v1-0009-WIP-Use-streaming-reads-in-vacuum.patch though: > > 4 files changed, 244 insertions(+), 78 deletions(-) > > The current prefetching logic in vacuumlazy.c is pretty hairy, so I hoped >

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 1:03 PM Andres Freund wrote: > I suspect that medium term the better approach would be to be much more > aggressive about setting all-visible, including as part of page-level > visibility checks, and to deal with the concern of vacuum not processing such > pages soon by not

Re: Annoying build warnings from latest Apple toolchain

I wrote: > Since updating to Xcode 15.0, my macOS machines have been > spitting a bunch of linker-generated warnings. ... > some program links complain > ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport' I found that this is being caused by the libpq_pgport hack in Makefile.glob

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 13:14:41 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 1:03 PM Andres Freund wrote: > > I suspect that medium term the better approach would be to be much more > > aggressive about setting all-visible, including as part of page-level > > visibility checks, and to deal

Re: Checks in RegisterBackgroundWorker.()

Here's a new version of these patches. I fixed one comment and ran pgindent, no other changes. -- Heikki Linnakangas Neon (https://neon.tech) From 1984e81c4191427fa2e358a664291edbf8d566ea Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 27 Sep 2023 23:39:09 +0300 Subject: [PATCH v2

Re: Annoying build warnings from latest Apple toolchain

I wrote: > I've not yet looked at the meson build infrastructure to > see if it needs a corresponding change. I think it doesn't, as long as all the relevant build targets write their dependencies with "frontend_code" before "libpq". (The need for this is, of course, documented nowhere. The state

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > On 2023-09-27 13:14:41 -0700, Peter Geoghegan wrote: > > As a general rule, I think that we're better of gambling against > > future FPIs, and then pulling back if we go too far. The fact that we > > went one VACUUM operation without the workl

Re: Streaming I/O, vectored I/O (WIP)

On Thu, Sep 28, 2023 at 9:13 AM Andres Freund wrote: > On 2023-09-27 21:33:15 +0300, Heikki Linnakangas wrote: > > Looking at the later patch that introduces the streaming read API, seems > > that it finishes all the reads, so I suppose we don't need an abort > > function. Does it all get cleaned

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 2:26 PM Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > > I think we need to make vacuums on large tables much more aggressive than > > they > > are now, independent of opportunistic freezing heuristics. It's idiotic that > > on large table

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote: > I don't think going for size_t is a viable path for fixing this. I'm pretty > sure the initial patch would trigger a type mismatch from guc_tables.c - we > don't have infrastructure for size_t GUCs. Nothing marked as PGDLLIMPORT uses

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 3:25 PM Robert Haas wrote: > > On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > > One way to deal with that would be to not track the average age in > > LSN-difference-bytes, but convert the value to some age metric at that > > time. If we e.g. were to convert the b

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 4:09 PM Melanie Plageman wrote: > At the risk of seeming too execution-focused, I want to try and get more > specific. Here is a description of an example implementation to test my > understanding: > > In table-level stats, save two numbers: younger_than_cpt/older_than_cpt

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

On Fri, 8 Sept 2023 at 09:41, Robert Haas wrote: > > On Tue, Sep 5, 2023 at 8:07 AM Richard Guo wrote: > > Yeah, this seems an omission in commit 45be99f8. > > It's been a while, but I think I omitted this deliberately because I > didn't really understand the value of it and wanted to keep the >

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc wrote: > > On Wed, 27 Sep 2023 12:58:54 + > "Hayato Kuroda (Fujitsu)" wrote: > > > > Should the committer be interested, your patch applies cleanly > > > and the docs build as expected. > > > > Yeah, but cfbot accepted previous version. Did you ha

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

On Fri, 8 Sept 2023 at 19:14, Richard Guo wrote: > explain select * from partsupp join lineitem on l_partkey > ps_partkey; > QUERY PLAN > -- > Gather (cost=0.00..1807085.44 r

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 7:39 PM Peter Geoghegan wrote: > > On Wed, Sep 27, 2023 at 4:09 PM Melanie Plageman > wrote: > > At the risk of seeming too execution-focused, I want to try and get more > > specific. Here is a description of an example implementation to test my > > understanding: > > > >

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, 28 Sep 2023 09:49:03 +1000 Peter Smith wrote: > On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc > wrote: > > > > On Wed, 27 Sep 2023 12:58:54 + > > "Hayato Kuroda (Fujitsu)" wrote: > > > > > > Should the committer be interested, your patch applies cleanly > > > > and the docs build

Re: Fail hard if xlogreader.c fails on out-of-memory

On Tue, Sep 26, 2023 at 06:28:30PM -0700, Noah Misch wrote: > On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote: >> What Michael wants to do now is remove the 2004-era assumption that >> malloc failure implies bogus data. It must be pretty unlikely in a 64 >> bit world with overcommitte

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:27 PM Peter Geoghegan wrote: > > On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > > I am much more concerned about cases where > > opportunistic freezing requires an FPI - it'll often *still* be the right > > choice to freeze the page, but we need a way to prevent

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:20 PM Melanie Plageman wrote: > > Can you define "unfreeze"? I don't know if this newly invented term > > refers to unsetting a page that was marked all-frozen following (say) > > an UPDATE, or if it refers to choosing to not freeze when the option > > was available (in t

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 17:43:04 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 5:20 PM Melanie Plageman > wrote: > > > Can you define "unfreeze"? I don't know if this newly invented term > > > refers to unsetting a page that was marked all-frozen following (say) > > > an UPDATE, or if it refe

Re: Add test module for Table Access Method

On Sat, Jun 03, 2023 at 07:42:36PM -0400, Fabrízio de Royes Mello wrote: > So in order to improve things a bit in this area I'm proposing to add a > test module for Table Access Method similar what we already have for Index > Access Method. > > This code is based on the "blackhole_am" implemented

Re: Set enable_seqscan doesn't take effect?

On Thu, 28 Sept 2023 at 13:47, jacktby jacktby wrote: > > postgres=# SET enable_seqscan = off; > SET > postgres=# explain select * from t; >QUERY PLAN > - > Seq Scan on t (cost=100.00.

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 10:30 AM Karl O. Pinc wrote: > > On Thu, 28 Sep 2023 09:49:03 +1000 > Peter Smith wrote: > > > On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc > > wrote: > > > > > > On Wed, 27 Sep 2023 12:58:54 + > > > "Hayato Kuroda (Fujitsu)" wrote: > > > > > > > > Should the commit

Re: [PGdocs] fix description for handling pf non-ASCII characters

Peter Smith writes: > I had in mind something like a SHIFT-JIS encoding where a single > "character" may include some trail bytes that happen to be in the > ASCII printable range. AFAIK because the new logic is processing > bytes, not characters, I thought the end result could be a mix of > escape

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 6:07 PM Andres Freund wrote: > > I would be sure to look out for new inserts that "unfreeze" pages, too > > -- ideally you'd have instrumentation that caught that, in order to > > get a general sense of the extent of the problem in each of your > > chosen representative wor

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:42 PM Melanie Plageman wrote: > On Wed, Sep 27, 2023 at 5:27 PM Peter Geoghegan wrote: > > What about my idea of holding back when some tuples are already frozen > > from before? Admittedly that's still a fairly raw idea, but something > > along those lines seems promisi

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

On Thu, 28 Sept 2023 at 02:37, Ranier Vilela wrote: >> Please check [1] for the mention of: >> >> "The fastest way to get your patch rejected is to make unrelated >> changes. Reformatting lines that haven't changed, changing unrelated >> comments you felt were poorly worded, touching code not nece

Re: Eager page freeze criteria clarification

On 2023-09-27 19:09:41 -0400, Melanie Plageman wrote: > On Wed, Sep 27, 2023 at 3:25 PM Robert Haas wrote: > > > > On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > > > One way to deal with that would be to not track the average age in > > > LSN-difference-bytes, but convert the value to so

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

Hi, On 2023-09-28 07:53:45 +0900, Michael Paquier wrote: > On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote: > > Frankly, it seems like a quite bad idea to have such a high limit for > > pgstat_track_activity_query_size. The overhead such a high value has will > > surprise people... >

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 11:19 AM Tom Lane wrote: > > ... trailing bytes that could be mistaken for ASCII are precisely > the property that causes us to reject an encoding as not backend-safe. Oh, that is good to know. Thanks for the information. == Kind Regards, Peter Smith. Fujitsu Australi

Re: RFC: Logging plan of the running query

On 2023-09-25 18:49, Andrey Lepikhov wrote: On 25/9/2023 14:21, torikoshia wrote: On 2023-09-20 14:39, Lepikhov Andrei wrote: Hmm, as a test, I made sure to call ProcessLogQueryPlanInterrupt() on all CFI using v28-0002-Testing-attempt-logging-plan-on-ever-CFI-call.patch, and then ran the foll

Re: Index range search optimization

On Wed, Sep 27, 2023 at 9:41 AM Alexander Korotkov wrote: > Fixed typo inficating => indicating as pointed by Pavel. > Peter, what do you think about the current shape of the patch? I'll try to get to this tomorrow. I'm rather busy with moving home at the moment, unfortunately. -- Peter Geoghe

Re: RFC: Logging plan of the running query

On 28/9/2023 09:04, torikoshia wrote: On 2023-09-25 18:49, Andrey Lepikhov wrote: On 25/9/2023 14:21, torikoshia wrote: On 2023-09-20 14:39, Lepikhov Andrei wrote: Hmm, as a test, I made sure to call ProcessLogQueryPlanInterrupt() on all CFI using v28-0002-Testing-attempt-logging-plan-on-ever

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Karl, Thank you for giving comments! PSA new version. I attached two patches - one is for HEAD, and another one is for REL_16_STABLE branch. As shown below, PG16 has the same behavior. ``` psql (16beta3) Type "help" for help. postgres=# SET application_name TO 'あああ'; SET postgres=# SHOW app

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Peter, Thank you for reviewing! > > > > > A. A patch which completely follows your comments. The name is > > > > > "v3-0001-...patch". Cfbot tests it. > > > > > B. A patch which completely follows Peter's comments [1]. The > > > > > name is "Peter_v3-txt". > > > > > C. A patch which foll

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Tom, Thank you for giving a comment! New patch is available in [1]. > I'd be inclined to keep the text as simple as possible and not focus on > the distinction between bytes and characters. > Okay, in the latest version, the word "byte" was removed. [1]: https://www.postgresql.org/message

Re: Streaming I/O, vectored I/O (WIP)

On 31/08/2023 07:00, Thomas Munro wrote: Currently PostgreSQL reads (and writes) data files 8KB at a time. That's because we call ReadBuffer() one block at a time, with no opportunity for lower layers to do better than that. This thread is about a model where you say which block you'll want next

RE: [PGdocs] fix description for handling pf non-ASCII characters

> I attached two patches - one is for HEAD, and another one is for REL_16_STABLE > branch. As shown below, PG16 has the same behavior. Hmm, cfbot got angry because it tried to apply both of patches. To avoid it, I repost renamed patch. (I'm happy if we can specify the target branch of patches) S

Re: Set enable_seqscan doesn't take effect?

> 2023年9月28日 01:07，Andres Freund 写道： > > Hi, > > On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: >> postgres=# SET enable_seqscan = off; >> SET >> postgres=# explain select * from t; >> QUERY PLAN >>

Re: Set enable_seqscan doesn't take effect?

> 2023年9月28日 01:07，Andres Freund 写道： > > Hi, > > On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: >> postgres=# SET enable_seqscan = off; >> SET >> postgres=# explain select * from t; >> QUERY PLAN >> -

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 03:23:30AM +, Hayato Kuroda (Fujitsu) wrote: > Hmm, cfbot got angry because it tried to apply both of patches. To avoid it, > I repost renamed patch. > (I'm happy if we can specify the target branch of patches) I was looking at this thread overall, the three v3 flavors

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier wrote in > My apologies for the long message, but this deserves some attention, > IMHO. > > So, any thoughts? Sorry for being late. However, I agree with David's concern regarding the unnecessary inconvenience it introduces. I'd like to main

  1   2   >