Re: proposal: psql: show current user in prompt

so 27. 1. 2024 v 0:04 odesílatel Jelte Fennema-Nio napsal: > On Fri, 26 Jan 2024 at 21:35, Pavel Stehule > wrote: > > I see a possibility of disabling reporting as possibly dangerous. > Without reporting encoding you can break psql. So it should be limited just > to few values where is known

Re: cleanup patches for incremental backup

Hello Robert, 26.01.2024 21:37, Robert Haas wrote: On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart wrote: On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: Here is v2 with that addition. Looks reasonable. Thanks for the report & review. I have committed that version. While

Re: [ psql - review request ] review request for \d+ tablename, \d+ indexname indenting

On Wed, 22 Nov 2023 at 21:54, Daniel Verite wrote: > > Shlok Kyal wrote: > > > > The error was corrected and a new diff file was created. > > > The diff file was created based on 16 RC1. > > > We confirmed that 5 places where errors occurred when performing > > > make check were changed

Re: MultiXact\SLRU buffers configuration

> On 20 Jan 2024, at 08:31, vignesh C wrote: > > On Mon, 9 Jan 2023 at 09:49, Andrey Borodin wrote: >> >> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote: >>> does not apply on top of HEAD as in [1], please post a rebased patch: >>> >> Thanks! Here's the rebase. > > I'm seeing that there

Re: A performance issue with Memoize

Hello, 27.01.2024 00:09, Tom Lane wrote: David Rowley writes: On Sat, 27 Jan 2024 at 09:41, Tom Lane wrote: drongo and fairywren are consistently failing the test case added by this commit. I'm not quite sure why the behavior of Memoize would be platform-specific when we're dealing with

Re: Synchronizing slots from primary to standby

On Thu, Jan 25, 2024 at 6:42 PM Zhijie Hou (Fujitsu) wrote: > > Here is the V69 patch set which includes the following changes. > > V69-0001, V69-0002 > Few minor comments on v69-0001 1. In libpqrcv_create_slot(), I see we are using two types of syntaxes based on 'use_new_options_syntax' (aka

Re: Reducing connection overhead in pg_upgrade compat check phase

On Fri, 27 Oct 2023 at 18:50, Daniel Gustafsson wrote: > > Attached is a v10 rebase of this patch which had undergone significant bitrot > due to recent changes in the pg_upgrade check phase. This brings in the > changes into the proposed structure without changes to queries, with no >

Re: Improving btree performance through specializing by key shape, take 2

On Mon, 30 Oct 2023 at 21:50, Matthias van de Meent wrote: > > On Thu, 26 Oct 2023 at 00:36, Peter Geoghegan wrote: > > Most of the work with something like > > this is the analysis of the trade-offs, not writing code. There are > > all kinds of trade-offs that you could make with something like

Re: User functions for building SCRAM secrets

On Sat, 2 Dec 2023 at 12:22, John Naylor wrote: > > On Wed, Mar 22, 2023 at 9:06 PM Jonathan S. Katz wrote: > > > > Maybe I'm not conveying the problem this is solving -- I'm happy to go > > one more round trying to make it clearer -- but if this is not clear, > > it'd be good to at develop an

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

On Tue, 2 Jan 2024 at 20:28, Daniel Verite wrote: > > Hi, > > PFA a rebased version. CFBot shows that the patch does not apply anymore as in [1]: === Applying patches on top of PostgreSQL commit ID a3a836fb5e51183eae624d43225279306c2285b8 === === applying patch

Re: Support run-time partition pruning for hash join

On Tue, 7 Nov 2023 at 13:25, Richard Guo wrote: > > > On Mon, Nov 6, 2023 at 11:00 PM Alexander Lakhin wrote: >> >> Please look at a warning and an assertion failure triggered by the >> following script: >> set parallel_setup_cost = 0; >> set parallel_tuple_cost = 0; >> set

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Fri, 19 Jan 2024 at 10:50, Michael Paquier wrote: > > On Thu, Jan 18, 2024 at 09:25:16AM +0100, Anthonin Bonnefoy wrote: > > From what I can tell, there's no change in the behaviour. All paths > > would eventually go through HandleSlashCmds's cleaning logic. This is > > also mentioned in

Re: Some revises in adding sorting path

On Mon, 17 Jul 2023 at 14:25, Richard Guo wrote: > > > On Wed, Mar 29, 2023 at 4:00 AM David Rowley wrote: >> >> If you write some tests for this code, it will be useful to prove that >> it actually does something, and also that it does not break again in >> the future. I don't really want to

Re: Separate memory contexts for relcache and catcache

On Wed, 3 Jan 2024 at 16:56, Melih Mutlu wrote: > > Hi, > > torikoshia , 4 Ara 2023 Pzt, 07:59 tarihinde şunu > yazdı: >> >> Hi, >> >> I also think this change would be helpful. >> >> I imagine you're working on the Andres's comments and you already notice >> this, but v1 patch cannot be applied

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

On Tue, 5 Dec 2023 at 16:25, Andrei Lepikhov wrote: > > Here is fresh version with the pg_dump.pl regex fixed. Now it must pass > buildfarm. > > Under development: > 1. Explanation of the general idea in comments (Robert's note) > 2. Issue with hiding some optimizations (Alexander's note and

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

On Tue, 31 Oct 2023 at 10:48, Ashutosh Bapat wrote: > > On Thu, Sep 14, 2023 at 4:39 PM Ashutosh Bapat > wrote: > > > > The patch set is thus > > 0001 - patch used to measure memory used during planning > > > > 0002 - Patch to free intermediate Relids computed by > >

Re: dblink query interruptibility

On Thu, Jan 25, 2024 at 12:28:43PM +0900, Fujii Masao wrote: > On Thu, Jan 25, 2024 at 5:45 AM Noah Misch wrote: > > On Thu, Jan 25, 2024 at 04:23:39AM +0900, Fujii Masao wrote: > > > I found that this patch was committed at d3c5f37dd5 and changed the > > > error message in postgres_fdw slightly.

Re: Request for comment on setting binary format output per session

On Mon, 31 Jul 2023 at 21:58, Dave Cramer wrote: > > > Dave Cramer > > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson wrote: >> >> > On 25 Apr 2023, at 16:47, Dave Cramer wrote: >> >> > Patch attached with comments removed >> >> This patch no longer applies, please submit a rebased version

Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500

On Mon, 8 Jan 2024 at 22:21, Tom Lane wrote: > > Richard Guo writes: > > On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote: > >> Thanks for the report! I guess we need something like the attached. > > > +1. > > Pushed, thanks for looking at it. I have changed the status of the commitfest entry to

Re: [CAUTION!! freemail] Re: Partial aggregates pushdown

On Thu, 7 Dec 2023 at 05:41, fujii.y...@df.mitsubishielectric.co.jp wrote: > > Hi Mr.Haas. > > > -Original Message- > > From: Robert Haas > > Sent: Wednesday, December 6, 2023 10:25 PM > > On Wed, Dec 6, 2023 at 3:41 AM fujii.y...@df.mitsubishielectric.co.jp > > wrote: > > > Are you

Re: [PoC/RFC] Multiple passwords, interval expirations

On Tue, 10 Oct 2023 at 16:37, Gurjeet Singh wrote: > > > On Mon, Oct 9, 2023 at 2:31 AM Gurjeet Singh wrote: > > > > > > Next steps: > > > - Break the patch into a series of smaller patches. > > > - Add TAP tests (test the ability to actually login with these passwords) > > > - Add/update

Re: Opportunistically pruning page before update

On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote: > > On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote: > > > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote: > > > > > > See rebased patch attached. > > > > I just realized I left a change in during the rebase that wasn't necessary. >

Re: Bug: The "directory" control parameter does not work

On Jan 26, 2024, at 5:05 PM, David E. Wheeler wrote: > I made a simpler test case here: > > https://github.com/theory/test-extension-directory > > Not the difference between actual and expected output. Bah! Need to also set `MODULEDIR = extension/click` and then it works. D

Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

On Fri, 26 Jan 2024 at 18:19, Alvaro Herrera wrote: > Yeah, I see that point of view as well. I like the end result; the > additional protos in libpq-int.h don't bother me. Does anybody else > wants to share their opinion on it? If none, then I'd consider going > ahead with this version. To

Re: proposal: psql: show current user in prompt

On Fri, 26 Jan 2024 at 21:35, Pavel Stehule wrote: > I see a possibility of disabling reporting as possibly dangerous. Without > reporting encoding you can break psql. So it should be limited just to few > values where is known behave. I agree that client_encoding is a GUC that likely all

Re: Bug: The "directory" control parameter does not work

On Jan 26, 2024, at 4:40 PM, David E. Wheeler wrote: > But it doesn’t seem to work. I tried this experiment: I made a simpler test case here: https://github.com/theory/test-extension-directory Not the difference between actual and expected output. Best, David

Bug: The "directory" control parameter does not work

Hackers, I wanted to try to customize the subdirectory for an extension. The docs[1] say: > directory (string) > > The directory containing the extension's SQL script file(s). Unless an > absolute path is given, the name is relative to the installation's SHAREDIR > directory. The default

Re: make dist using git archive

Hello, meson developer here. On 1/23/24 4:30 AM, Peter Eisentraut wrote: > On 22.01.24 21:04, Tristan Partin wrote: >> I am not really following why we can't use the builtin Meson dist >> command. The only difference from my testing is it doesn't use a >> --prefix argument. > > Here are some

Re: A performance issue with Memoize

David Rowley writes: > On Sat, 27 Jan 2024 at 09:41, Tom Lane wrote: >> drongo and fairywren are consistently failing the test case added >> by this commit. I'm not quite sure why the behavior of Memoize >> would be platform-specific when we're dealing with integers, >> but ... > Maybe

Re: A performance issue with Memoize

On Sat, 27 Jan 2024 at 09:41, Tom Lane wrote: > > David Rowley writes: > > I've adjusted the comments to what you mentioned and also leaned out > > the pretty expensive test case to something that'll run much faster > > and pushed the result. > > drongo and fairywren are consistently failing the

Re: Functions to return random numbers in a given range

Thank you for the patch. I applied this patch manually to the master branch, resolving a conflict in `numeric.h`. It successfully passed both `make check` and `make check-world`. Best regards, David

Re: A performance issue with Memoize

David Rowley writes: > I've adjusted the comments to what you mentioned and also leaned out > the pretty expensive test case to something that'll run much faster > and pushed the result. drongo and fairywren are consistently failing the test case added by this commit. I'm not quite sure why the

Re: proposal: psql: show current user in prompt

pá 26. 1. 2024 v 11:40 odesílatel Jelte Fennema-Nio napsal: > On Thu, 25 Jan 2024 at 21:43, Pavel Stehule > wrote: > > 2. using GUC for all reported GUC looks not too readable. Maybe it > should be used just for customized reporting, not for default > > I thought about this too, because indeed

Re: psql: add \create_function command

idea: what about custom functions for (each) IDE, which calls psql -c "CREATE FUNCTION ..." when the user saves the file? (it would easy to prototype for emacs...) (obviously, this isn't a core feature...) On Fri, Jan 26, 2024 at 3:19 PM Pavel Stehule wrote: > > > pá 26. 1. 2024 v 21:17

Re: psql: add \create_function command

pá 26. 1. 2024 v 21:17 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I don't know, maybe I have a problem with the described use case. I > cannot > > imagine holding the body and head of PL routines in different places and > I > > don't understand the necessity to join it. > > It

Re: psql: add \create_function command

Pavel Stehule writes: > I don't know, maybe I have a problem with the described use case. I cannot > imagine holding the body and head of PL routines in different places and I > don't understand the necessity to join it. It seems a little weird to me too, and I would vote against accepting

Re: psql: add \create_function command

pá 26. 1. 2024 v 21:04 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > but why you need to do in psql? - you can prepare content outside and > > execute just like echo "CREATE FUNCTION " | psql > > The bit that's probably hard if you're trying to do this in a shell > script is

Re: psql: add \create_function command

Pavel Stehule writes: > but why you need to do in psql? - you can prepare content outside and > execute just like echo "CREATE FUNCTION " | psql The bit that's probably hard if you're trying to do this in a shell script is "quote this data as a SQL string literal". psql can get that right

Re: Add minimal C example and SQL registration example for custom table access methods.

On Wed, Nov 15, 2023 at 8:29 PM Roberto Mello wrote: > > Suggestion: > > In the C example you added you mention in the comment: > > + /* Methods from TableAmRoutine omitted from example, but all > + non-optional ones must be provided here. */ > > Perhaps you could provide a "see " to point

Re: Add minimal C example and SQL registration example for custom table access methods.

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:tested, passed Hello, I've reviewed your patch and it applies correctly and the

Re: psql: add \create_function command

walt...@technowledgy.de writes: > Pavel Stehule: >> looks a little bit obscure - why do you need to do it from psql? And how >> frequently do you do it? > I store all my SQL code in git and use "psql -e" to "bundle" it into an > extension, which is then deployed to production. > The code is

Re: psql: add \create_function command

pá 26. 1. 2024 v 20:45 odesílatel napsal: > Pavel Stehule: > > looks a little bit obscure - why do you need to do it from psql? And how > > frequently do you do it? > > I store all my SQL code in git and use "psql -e" to "bundle" it into an > extension, which is then deployed to production. >

Re: psql: add \create_function command

On Fri, Jan 26, 2024 at 12:23 PM Tom Lane wrote: > > \set fbody `cat source_file.txt` > CREATE FUNCTION foo() RETURNS whatever AS :'fbody' LANGUAGE ...; > > and maybe we should say that that's sufficient. I really don't have a problem, and kinda prefer, using psql variables this way but feel

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Thu, Jan 11, 2024 at 10:48 AM Bharath Rupireddy wrote: > > Hi, > > Replication slots in postgres will prevent removal of required > resources when there is no connection using them (inactive). This > consumes storage because neither required WAL nor required rows from > the user tables/system

Re: make dist using git archive

On Fri Jan 26, 2024 at 12:28 AM CST, Peter Eisentraut wrote: On 25.01.24 17:25, Tristan Partin wrote: > For what it's worth, I run Meson 1.3, and the behavior of generating the > tarballs even though it is a dirty tree still occurred. In the new patch > you seem to say it was fixed in 0.60.

Re: psql: add \create_function command

Pavel Stehule: looks a little bit obscure - why do you need to do it from psql? And how frequently do you do it? I store all my SQL code in git and use "psql -e" to "bundle" it into an extension, which is then deployed to production. The code is spread over many files, which include other

Re: psql: add \create_function command

Tom Lane: Or we could cut out the intermediate variable altogether by inventing something that works like :'...' but reads from a file not a variable. That might be too specialized though, and I'm not sure about good syntax for it either. Maybe like CREATE FUNCTION foo() RETURNS whatever AS

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Fri, 2024-01-26 at 19:31 +0530, Bharath Rupireddy wrote: > Are you suggesting to error out instead of returning 0? We'd do neither of those things, because no caller should actually call it while RecoveryInProgress() or on a different timeline. > How about > returning a negative value

Re: psql: add \create_function command

Pavel Stehule writes: > pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez napsal: >> To solve the above issue, this patch adds a psql command to create a >> function and obtain its body from another file. It is used as: >> \create_function from ./data/max.py max(int,int) returns int LANGUAGE >>

Re: Patch: Improve Boolean Predicate JSON Path Docs

On Jan 25, 2024, at 11:03, Tom Lane wrote: > I changed the preceding para to say "... check expressions are > required in ...", which I thought was sufficient to cover that. > Also, the tabular description of the operator tells you not to do it. Yeah, that’s good. I was perhaps leaning into

Re: psql: add \create_function command

Hi pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez napsal: > Hello hackers, > > Currently a function definition must include its body inline. Because of > this, when storing function definitions in files, linters and syntax > highlighters for non-SQL languages (python, perl, tcl, etc) won't

psql: add \create_function command

Hello hackers, Currently a function definition must include its body inline. Because of this, when storing function definitions in files, linters and syntax highlighters for non-SQL languages (python, perl, tcl, etc) won't work. An example can be seen on:

Re: cleanup patches for incremental backup

On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart wrote: > On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: > > Here is v2 with that addition. > > Looks reasonable. Thanks for the report & review. I have committed that version. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Printing backtrace of postgres processes

On Fri, Jan 26, 2024 at 4:11 PM Alvaro Herrera wrote: > Thanks for reviewing. > > +You can get the file name and line number from the logged details by > > using > > +gdb/addr2line in linux platforms (users must ensure gdb/addr2line is > > +already installed). > > This doesn't read

Re: Hide exposed impl detail of wchar.c

Nathan Bossart writes: > I see that I was planning on back-patching this to v16, but since > is_valid_ascii() was introduced in v15, I'm wondering if it'd be better to > back-patch it there so that is_valid_ascii() lives in the same file for all > versions where it exists. Thoughts? Yeah, if

Re: [PATCH] Add sortsupport for range types and btree_gist

Am Freitag, dem 26.01.2024 um 18:31 +0530 schrieb vignesh C: > CFBot shows that the patch does not apply anymore as in [1]: > === Applying patches on top of PostgreSQL commit ID I've started working on it and planning to submit a polished patch for the upcoming CF.

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 26 Jan 2024, at 22:38, Alvaro Herrera wrote: > > This is OK because in the > default compilation each file only has 32 segments, so that requires > only 32 lwlocks held at once while the file is being deleted. Do we account somehow that different subsystems do not accumulate

Re: Hide exposed impl detail of wchar.c

On Thu, Jan 04, 2024 at 04:43:29PM -0600, Nathan Bossart wrote: > On Mon, Nov 20, 2023 at 10:39:43PM -0600, Nathan Bossart wrote: >> Alright. The next minor release isn't until February, so I'll let this one >> sit a little while longer in case anyone objects to back-patching something >> like

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Fri, Jan 26, 2024 at 11:44 AM Robert Haas wrote: > Thanks to you for the patches, and to Peter for participating in the > discussion which, IMHO, was very helpful in clarifying things. Glad I could help. -- Peter Geoghegan

Re: cleanup patches for incremental backup

On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: > Here is v2 with that addition. Looks reasonable. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

I've continued to review this and decided that I don't like the mess this patch proposes in order to support pg_commit_ts's deletion of all files. (Yes, I know that I was the one that proposed this idea. It's still a bad one). I'd like to change that code by removing the limit that we can only

Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

On 2024-Jan-26, Jelte Fennema-Nio wrote: > Okay I tried doing that. I think the end result is indeed quite nice, > having all the cancellation related functions together in a file. But > it did require making a bunch of static functions in fe-connect > extern, and adding them to libpq-int.h. On

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Fri, Jan 26, 2024 at 11:44 AM Robert Haas wrote: > > On Thu, Jan 25, 2024 at 12:25 PM Robert Haas wrote: > > I think you're probably correct. I just didn't realize what was meant. > > I tweaked your v12 based on this discussion and committed the result. > > Thanks to you for the patches, and

Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

On Fri, 26 Jan 2024 at 13:11, Alvaro Herrera wrote: > I wonder, would it make sense to put all these new functions in a > separate file fe-cancel.c? Okay I tried doing that. I think the end result is indeed quite nice, having all the cancellation related functions together in a file. But it did

Re: Supporting MERGE on updatable views

Thanks for working on this. The patch looks well finished. I didn't try to run it, though. I gave it a read and found nothing to complain about, just these two pretty minor comments: On 2024-Jan-26, Dean Rasheed wrote: > diff --git a/src/backend/executor/execMain.c

Re: pg_upgrade failing for 200+ million Large Objects

vignesh C writes: > CFBot shows that the patch does not apply anymore as in [1]: > === Applying patches on top of PostgreSQL commit ID > 46a0cd4cefb4d9b462d8cc4df5e7ecdd190bea92 === > === applying patch ./v9-005-parallel_pg_restore.patch > patching file src/bin/pg_upgrade/pg_upgrade.c > Hunk #3

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 25, 2024 at 12:25 PM Robert Haas wrote: > I think you're probably correct. I just didn't realize what was meant. I tweaked your v12 based on this discussion and committed the result. Thanks to you for the patches, and to Peter for participating in the discussion which, IMHO, was

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On 2024-Jan-26, Alvaro Herrera wrote: > On 2024-Jan-26, vignesh C wrote: > > > Please post an updated version for the same. > > Here's a rebase. I only fixed the conflicts, didn't review. Hmm, but I got the attached regression.diffs with it. I didn't investigate further, but it looks like

Re: cleanup patches for incremental backup

On Thu, Jan 25, 2024 at 11:08 AM Nathan Bossart wrote: > On Thu, Jan 25, 2024 at 10:06:41AM -0500, Robert Haas wrote: > > On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart > > wrote: > >> That seems like a reasonable starting point. Even if it doesn't help > >> determine the root cause, it should

Re: MERGE ... WHEN NOT MATCHED BY SOURCE

On 2024-Jan-26, Dean Rasheed wrote: > I think it has had a decent amount of review and all the review > comments have been addressed. I'm not quite sure from Alvaro's last > comment whether he was implying that he thought it was ready for > commit. Well, firstly this is clearly a feature we want

Re: MERGE ... WHEN NOT MATCHED BY SOURCE

n Fri, 26 Jan 2024 at 14:59, vignesh C wrote: > > CFBot shows that the patch does not apply anymore as in [1]: > Rebased version attached. Regards, Dean diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml new file mode 100644 index f8f83d4..6ef0c2b --- a/doc/src/sgml/mvcc.sgml +++

Re: MERGE ... WHEN NOT MATCHED BY SOURCE

On Mon, 22 Jan 2024 at 02:10, Peter Smith wrote: > > Hi, this patch was marked in CF as "Needs Review" [1], but there has > been no activity on this thread for 6+ months. > > Is anything else planned? Can you post something to elicit more > interest in the latest patch? Otherwise, if nothing

Re: Add new error_action COPY ON_ERROR "log"

On Thu, Jan 25, 2024 at 9:42 AM torikoshia wrote: > Hi, > > As described in 9e2d870119, COPY ON_EEOR is expected to have more > "error_action". > (Note that option name was changed by b725b7eec) > > I'd like to have a new option "log", which skips soft errors and logs > information that should

Re: POC: GROUP BY optimization

On Fri, Jan 26, 2024 at 10:38 AM Tom Lane wrote: > Sadly, that's not a small task: > > * We'd need to put effort into assigning more realistic procost > values --- preferably across the board, not just comparison functions. > As long as all the comparison functions have procost 1.0, you're > just

Re: POC: GROUP BY optimization

Robert Haas writes: > On Tue, Dec 26, 2023 at 10:23 PM Tom Lane wrote: >> I think it's a fool's errand to even try to separate different sort >> column orderings by cost. We simply do not have sufficiently accurate >> cost information. The previous patch in this thread got reverted because >>

Re: Add new COPY option REJECT_LIMIT

On Fri, Jan 26, 2024 at 2:49 AM torikoshia wrote: > Hi, > > 9e2d870 enabled the COPY command to skip soft error, and I think we can > add another option which specifies the maximum tolerable number of soft > errors. > > I remember this was discussed in [1], and feel it would be useful when >

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Wed, 4 Oct 2023 at 04:02, Ashutosh Bapat wrote: > > On Fri, Sep 29, 2023 at 8:36 AM Amit Langote wrote: > > IOW, something > > like the following would have sufficed: > > > > @@ -1735,6 +1735,10 @@ build_child_join_sjinfo(PlannerInfo *root, > > SpecialJoinInfo *parent_sjinfo, > > /* > > *

Re: POC: GROUP BY optimization

On Tue, Dec 26, 2023 at 10:23 PM Tom Lane wrote: > I think it's a fool's errand to even try to separate different sort > column orderings by cost. We simply do not have sufficiently accurate > cost information. The previous patch in this thread got reverted because > of that (well, also some

Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row

Hi, The option choice of "ignore" in the COPY ON_ERROR clause seems overly generic. There would seem to be two relevant ways to ignore bad column input data - drop the entire row or just set the column value to null. I can see us wanting to provide the set to null option and in any case having

Re: Small fix on COPY ON_ERROR document

On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote: > On Fri, 26 Jan 2024 00:00:57 -0700 > "David G. Johnston" wrote: > > > I will need to make this tweak and probably a couple others to my own > > suggestions in 12 hours or so. > > > > And here is my v2. Notably I choose to introduce the

Re: A failure in t/038_save_logical_slots_shutdown.pl

On Thu, Jan 25, 2024 at 5:07 PM Amit Kapila wrote: > > On Thu, Jan 25, 2024 at 4:27 PM Bharath Rupireddy > wrote: > > > > Thanks. I'll wait a while and then add it to CF to not lose it in the wild. > > > > Feel free to add it to CF. However, I do plan to look at it in the > next few days.

Re: Supporting MERGE on updatable views

On Mon, 30 Oct 2023 at 15:04, Dean Rasheed wrote: > > On Sun, 29 Oct 2023 at 17:17, Dean Rasheed wrote: > > > > On Sat, 28 Oct 2023 at 09:35, jian he wrote: > > > > > > Do we need to add > > > > We don't want to include MERGE in that sentence, because MERGE

Re: MERGE ... WHEN NOT MATCHED BY SOURCE

On Sat, 1 Jul 2023 at 18:04, Dean Rasheed wrote: > > On Tue, 21 Mar 2023 at 12:26, Alvaro Herrera wrote: > > > > On 2023-Mar-21, Dean Rasheed wrote: > > > > > Looking at it with fresh eyes though, I realise that I could have just > > > written > > > > > > action->qual = make_and_qual((Node

Re: Remove unused fields in ReorderBufferTupleBuf

On Fri, 2024-01-26 at 13:51 +0900, Masahiko Sawada wrote: > On Fri, Jan 26, 2024 at 1:24 PM wrote: > > > > On Thu, 2024-01-25 at 16:11 -0500, reid.thomp...@crunchydata.com wrote: > > > > > > I walked through v6 and didn't note any issues. > > Thank you for reviewing the patch! > Happy to. >

Re: Transaction timeout

On Fri, 26 Jan 2024 at 14:44, Andrey M. Borodin wrote: >> On 22 Jan 2024, at 11:23, Peter Smith wrote: >> >> Hi, This patch has a CF status of "Needs Review" [1], but it seems >> there was a CFbot test failure last time it was run [2]. Please have a >> look and post an updated version if

Re: Lockless queue of waiters in LWLock

On Sat, 20 Jan 2024 at 07:28, vignesh C wrote: > > On Sat, 26 Nov 2022 at 00:24, Pavel Borisov wrote: > > > > Hi, hackers! > > In the measurements above in the thread, I've been using LIFO wake > > queue in a primary lockless patch (and it was attached as the previous > > versions of a patch)

Re: PoC: prefetching index leaf pages (for inserts)

On Mon, 6 Nov 2023 at 22:36, Tomas Vondra wrote: > > Seems cfbot was not entirely happy about the patch, for two reasons: > > 1) enable_insert_prefetching definition was inconsistent (different > boot/default values, missing in .conf and so on) > > 2) stupid bug in execReplication, inserting

Re: pg_upgrade failing for 200+ million Large Objects

On Tue, 2 Jan 2024 at 23:03, Kumar, Sachin wrote: > > > On 11/12/2023, 01:43, "Tom Lane" > > wrote: > > > I had initially supposed that in a parallel restore we could > > have child workers also commit after every N TOC items, but was > > soon disabused of that idea.

RE: Current Connection Information

Hi Aleksander, >>I assume you wanted to reply to the mailing list and add me to cc: >>(aka "Reply to All") but sent the e-mail off-list by mistake, so >>quoting it here: Yes, tks for that. >>IMO it's worth trying submitting the patch, if your time permits it of course. I've been spending a

Re: logical decoding and replication of sequences, take 2

On Wed, Jan 24, 2024 at 12:46 PM Tomas Vondra wrote: > I did try to explain how this works (and why) in a couple places: > > 1) the commit message > 2) reorderbuffer header comment > 3) ReorderBufferSequenceIsTransactional comment (and nearby) > > It's possible this does not meet your

Re: POC: GROUP BY optimization

On Thu, 25 Jan 2024 at 01:15, Alexander Korotkov wrote: > > On Wed, Jan 24, 2024 at 7:38 PM Nathan Bossart > wrote: > > A recent buildfarm failure [0] seems to indicate a name collision with the > > "abc" index in the aggregates.sql test and the "abc" table in > > namespace.sql. > > > > [0] >

Re: [PATCH] Add native windows on arm64 support

On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote: > > On 2024-01-25 Th 20:32, Michael Paquier wrote: > > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote: > >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan > wrote: > >>> On 2024-01-25 Th 16:17, Dave Cramer wrote: > >>> Yeah, I think

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

On Wed, Jan 24, 2024 at 3:42 PM John Naylor wrote: > > On Tue, Jan 23, 2024 at 10:58 AM Masahiko Sawada > wrote: > > > > The new patches probably need to be polished but the VacDeadItemInfo > > idea looks good to me. > > That idea looks good to me, too. Since you already likely know what >

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Fri, Jan 26, 2024 at 8:31 AM Jeff Davis wrote: > > > PSA v20 patch set. > > 0001 is very close. I have the following suggestions: > > * Don't just return zero. If the caller is doing something we don't > expect, we want to fix the caller. I understand you'd like this to be > more like a

Re: Add new error_action COPY ON_ERROR "log"

On Fri, Jan 26, 2024 at 12:42 AM torikoshia wrote: > > Hi, > > As described in 9e2d870119, COPY ON_EEOR is expected to have more > "error_action". > (Note that option name was changed by b725b7eec) > > I'd like to have a new option "log", which skips soft errors and logs > information that should

Re: tablecmds.c/MergeAttributes() cleanup

On 24.01.24 07:27, Ashutosh Bapat wrote: While working on identity support and now while looking at the compression problem you referred to, I found MergeAttribute() to be hard to read. It's hard to follow high level logic in that function since the function is not modular. I took a stab at

Re: Confine vacuum skip logic to lazy_scan_skip

On Fri, 12 Jan 2024 at 05:12, Melanie Plageman wrote: > > v3 attached > > On Thu, Jan 4, 2024 at 3:23 PM Andres Freund wrote: > > > > Hi, > > > > On 2024-01-02 12:36:18 -0500, Melanie Plageman wrote: > > > Subject: [PATCH v2 1/6] lazy_scan_skip remove unnecessary local var > > > rel_pages > > >

Re: [PATCH] Compression dictionaries for JSONB

On Wed, 17 Jan 2024 at 19:52, Aleksander Alekseev wrote: > > Hi Shubham, > > > > > 8272749e added a few more arguments to CastCreate(). Here is the > > > > rebased patch. > > > > > > After merging afbfc029 [1] the patch needed a rebase. PFA v10. > > > > > > The patch is still in a PoC state and

Re: fix stats_fetch_consistency value in postgresql.conf.sample

On Sat, 20 Jan 2024 at 08:39, Michael Paquier wrote: > > On Sat, Jan 20, 2024 at 07:59:22AM +0530, vignesh C wrote: > > I'm seeing that there has been no activity in this thread for more > > than 8 months, I'm planning to close this in the current commitfest > > unless someone is planning to take

Re: [PATCH] Add support function for containment operators

On Sun, 21 Jan 2024 at 00:31, Tom Lane wrote: > > jian he writes: > > Now I see your point. If the transformed plan is right, the whole > > added code should be fine. > > but keeping the textrange_supp related test should be a good idea. > > since we don't have SUBTYPE_OPCLASS related sql tests.

  1   2   >