Avoid useless retrieval of defaults and check constraints in pg_dump -a

Hi, Currently, getTableAttrs() always retrieves info about columns defaults and check constraints, while this will never be used if --data-only option if used. This seems like a waste of resources, so here's a patch to skip those parts when the DDL won't be generated. diff --git a/src/bin/pg_dump/

Re: Default setting for enable_hashagg_disk

On Saturday, July 11, 2020, Tom Lane wrote: > "David G. Johnston" writes: > > On Sat, Jul 11, 2020 at 5:47 PM Tom Lane wrote: > >> It seems like a lot of the disagreement here is focused on Peter's > >> proposal to make hash_mem_multiplier default to 2.0. But it doesn't > >> seem to me that th

Re: ALTER TABLE validate foreign key dependency problem

On Thu, 9 Jul 2020 at 15:54, David Rowley wrote: > I think the fix is just to delay the foreign key validation when > there's a rewrite pending until the rewrite is complete. I looked over this again and only slightly reworded a comment. The problem exists as far back as 9.5 so I've attached 3 p

Re: Default setting for enable_hashagg_disk

"David G. Johnston" writes: > On Sat, Jul 11, 2020 at 5:47 PM Tom Lane wrote: >> It seems like a lot of the disagreement here is focused on Peter's >> proposal to make hash_mem_multiplier default to 2.0. But it doesn't >> seem to me that that's a critical element of the proposal. Why not just >

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 5:47 PM Tom Lane wrote: > Tomas Vondra writes: > > I don't know, but one of the main arguments against simply suggesting > > people to bump up work_mem (if they're hit by the hashagg spill in v13) > > was that it'd increase overall memory usage for them. It seems strange

Re: Default setting for enable_hashagg_disk

On Sun, Jul 12, 2020 at 2:27 AM Tom Lane wrote: > David Rowley writes: > > hmm yeah. It's unfortunate, but I'm not sure how I'd have implemented > > it differently. The problem is made worse by the fact that we'll only > > release the memory for the hash table during ExecEndHashJoin(). If the >

Re: Default setting for enable_hashagg_disk

I would be okay with a default of 1.0. Peter Geoghegan (Sent from my phone)

Re: proposal: possibility to read dumped table's name from file

On Mon, Jul 6, 2020 at 10:05 AM Pavel Stehule wrote: > > here is support for comment's line - first char should be # > Few comments: + str = fgets(*lineptr + total_chars, + *n - total_chars, + fp); + +

Re: Default setting for enable_hashagg_disk

Tomas Vondra writes: > I don't know, but one of the main arguments against simply suggesting > people to bump up work_mem (if they're hit by the hashagg spill in v13) > was that it'd increase overall memory usage for them. It seems strange > to then propose a new GUC set to a default that would re

Re: StartupMessage parameters - free-form or not?

Excellent, thanks! On Sat, Jul 11, 2020 at 8:43 PM Tom Lane wrote: > =?UTF-8?B?SmFrYSBKYW7EjWFy?= writes: > > I wrote a Postgres client and in it I allow the user to specify arbitrary > > StartupMessage parameters (Map). This is convenient > because > > the user can for example set search_path

Re: StartupMessage parameters - free-form or not?

=?UTF-8?B?SmFrYSBKYW7EjWFy?= writes: > I wrote a Postgres client and in it I allow the user to specify arbitrary > StartupMessage parameters (Map). This is convenient because > the user can for example set search_path without issuing a separate SET > query or encoding things into the "options" par

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 09:02:43AM -0700, David G. Johnston wrote: On Sat, Jul 11, 2020 at 7:22 AM Stephen Frost wrote: There now seems to be some suggestions that not only should we have a new GUC, but we should default to having it not be equal to work_mem (or 1.0 or whatever) and instead by

StartupMessage parameters - free-form or not?

Hi, I wrote a Postgres client and in it I allow the user to specify arbitrary StartupMessage parameters (Map). This is convenient because the user can for example set search_path without issuing a separate SET query or encoding things into the "options" parameter. The protocol documentation also s

Re: POC: postgres_fdw insert batching

On Fri, Jul 10, 2020 at 09:28:44AM +0500, Andrey V. Lepikhov wrote: On 6/28/20 8:10 PM, Tomas Vondra wrote: Now, the primary reason why the performance degrades like this is that while FDW has batching for SELECT queries (i.e. we read larger chunks of data from the cursors), we don't have that f

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 4:23 PM Tomas Vondra wrote: > I find that example rather suspicious. I mean, what exactly in the > GroupAgg plan would consume this memory? Surely it'd have to be some > node below the grouping, but sort shouldn't do that, no? > > Seems strange. Well, I imagine hash aggreg

Re: Default setting for enable_hashagg_disk

On Fri, Jul 10, 2020 at 10:00 PM David Rowley wrote: > hmm yeah. It's unfortunate, but I'm not sure how I'd have implemented > it differently. The problem is made worse by the fact that we'll only > release the memory for the hash table during ExecEndHashJoin(). If the > planner had some ability

Re: GSSENC'ed connection stalls while reconnection attempts.

I wrote: > Kyotaro Horiguchi writes: >> If psql connected using GSSAPI auth and server restarted, reconnection >> sequence stalls and won't return. > Yeah, reproduced here. (I wonder if there's any reasonable way to > exercise this scenario in src/test/kerberos/.) I tried writing such a test ba

Re: WIP: BRIN multi-range indexes

On Sat, Jul 11, 2020 at 03:32:43PM +0200, Sascha Kuhl wrote: Tomas Vondra schrieb am Sa., 11. Juli 2020, 13:24: On Fri, Jul 10, 2020 at 04:44:41PM +0200, Sascha Kuhl wrote: >Tomas Vondra schrieb am Fr., 10. Juli 2020, >14:09: > >> On Fri, Jul 10, 2020 at 06:01:58PM +0900, Masahiko Sawada wrot

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 09:49:43AM -0700, Peter Geoghegan wrote: On Sat, Jul 11, 2020 at 7:22 AM Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: > Have you got a better proposal that is reasonably implementable for v13? > (I do not accept the argument that "do nothing" is a better p

Re: pg_dump bug for extension owned tables

On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote: > > On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello > mailto:fabriziome...@gmail.com>> wrote: > > > > > > On Fri, Jun 26, 2020 at 11:24 AM Andrew Dunstan > > wrote: > > > > > > > > > On 6/26/20 9:5

Re: proposal: possibility to read dumped table's name from file

On Mon, Jul 06, 2020 at 06:34:15AM +0200, Pavel Stehule wrote: > >> > Comment support is still missing but easily added :) > >> Still missing from the latest patch. > > > > I can implement a comment support. But I am not sure about the format. The > > here is support for comment's line - first cha

Re: Support for NSS as a libpq TLS backend

> On 10 Jul 2020, at 07:10, Thomas Munro wrote: > > On Fri, Jul 3, 2020 at 11:51 PM Daniel Gustafsson wrote: >>> On 25 Jun 2020, at 17:39, Daniel Gustafsson wrote: On 15 May 2020, at 22:46, Daniel Gustafsson wrote: The 0001 patch contains the full NSS support, and 0002 is a fix for t

Re: min_safe_lsn column in pg_replication_slots view

On 2020-Jul-11, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Jul-09, Alvaro Herrera wrote: > >> I think we should define InvalidXLogSegNo to be ~((uint64)0) and add a > >> macro to test for that. > > > That's overkill really. I just used zero. Running > > contrib/test_decoding under va

Re: output columns of \dAo and \dAp

Alexander Korotkov writes: > The proposed patch is attached. This patch is fixes two points: > * Adds strategy number and purpose to output of \dAo > * Renames "Left/right arg type" columns of \dAp to "Registered left/right > type" I think that \dAp should additionally be changed to print the

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

Mark Dilger writes: > On Jul 10, 2020, at 11:00 PM, Michael Paquier wrote: >> I am not really a fan of this patch. I could see a benefit in >> switching to an enum so as for places where we use a switch/case >> without a default we would be warned if a new relkind gets added or if >> a value is

Re: Does TupleQueueReaderNext() really need to copy its result?

Hey Thomas, On Fri, Jul 10, 2020 at 7:30 PM Thomas Munro wrote: > > > I could reproduce the speed gain that you saw for a plan with a simple > > parallel sequential scan. However, I got no gain at all for a parallel > > hash join and parallel agg query. > > Right, it's not going to make a differe

Re: Reducing WaitEventSet syscall churn

Daniel Gustafsson writes: >> On 13 Mar 2020, at 08:21, Kyotaro Horiguchi wrote: >> The attached are: >> 0001-0004 Not changed >> 0005 Fix interface of PQregisterEventProc >> 0006 Add new libpq event for this use. >> 0007 Another version of "0006 Reuse a WaitEventSet in >> libpqwalreceiver.c" base

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

> On Jul 10, 2020, at 11:00 PM, Michael Paquier wrote: > > On Wed, Jul 01, 2020 at 05:04:19PM -0700, Mark Dilger wrote: >> Most of the work in this patch is mechanical replacement of if/else >> if/else statements which hinge on relkind to switch statements on >> relkind. The patch is not phil

Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

vignesh C writes: > On Tue, Jun 30, 2020 at 2:41 PM Bharath Rupireddy > wrote: >> I've added this patch to commitfest - https://commitfest.postgresql.org/28/. > I felt this patch is ready for committer, changing the status to ready > for committer. Pushed with some fiddling. Mainly, if we're g

Re: jsonpath versus NaN

Alexander Korotkov writes: > On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov > wrote: >> I understand both patches as fixes and propose to backpatch them to 12 >> if no objections. > Both patches are pushed. Thanks for taking care of that! regards, tom lane

Re: "tuple concurrently updated" in pg_restore --jobs

Justin Pryzby writes: > On Fri, Jul 10, 2020 at 05:36:28PM -0400, Tom Lane wrote: >> I'm not sure how far to back-patch it -- I think the parallel restore >> of ACLs behavior is not very old, but we might want to teach older >> pg_dump versions to insert the extra dependency anyway, for safety. >

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 7:22 AM Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Have you got a better proposal that is reasonably implementable for v13? > > (I do not accept the argument that "do nothing" is a better proposal.) > So, no, I don't agree that 'do nothing' (except r

Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

> On Jul 10, 2020, at 9:44 PM, Michael Paquier wrote: > > On Wed, Jul 08, 2020 at 10:00:47PM +0900, Michael Paquier wrote: >> There are two patches on this thread v2-0001 being much smaller than >> v2-0002. I have looked at 0001 for now, and, like Alvaro, this >> renaming makes sense to me.

Re: Index Skip Scan (new UniqueKeys)

> On Fri, Jul 10, 2020 at 05:03:37PM +, Floris Van Nee wrote: > > Also took another look at the patch now, and found a case of incorrect > data. It looks related to the new way of creating the paths, as I > can't recall seeing this in earlier versions. > > create table t1 as select a,b,b%5 as c

Re: Index Skip Scan (new UniqueKeys)

> On Wed, Jul 08, 2020 at 03:44:26PM -0700, Peter Geoghegan wrote: > > On Tue, Jun 9, 2020 at 3:20 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > * Btree-implementation contains btree specific code to implement amskip, > > introduced in the previous patch. > > The way that you're dealing wit

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 7:22 AM Stephen Frost wrote: > There now seems to be some suggestions that not only should we have a > new GUC, but we should default to having it not be equal to work_mem (or > 1.0 or whatever) and instead by higher, to be *twice* or larger whatever > the existing work_me

Re: WIP: BRIN multi-range indexes

Sorry, my topic is different Sascha Kuhl schrieb am Sa., 11. Juli 2020, 15:32: > > > > Tomas Vondra schrieb am Sa., 11. Juli > 2020, 13:24: > >> On Fri, Jul 10, 2020 at 04:44:41PM +0200, Sascha Kuhl wrote: >> >Tomas Vondra schrieb am Fr., 10. Juli >> 2020, >> >14:09: >> > >> >> On Fri, Jul 10,

Re: WIP: BRIN multi-range indexes

Tomas Vondra schrieb am Sa., 11. Juli 2020, 13:24: > On Fri, Jul 10, 2020 at 04:44:41PM +0200, Sascha Kuhl wrote: > >Tomas Vondra schrieb am Fr., 10. Juli > 2020, > >14:09: > > > >> On Fri, Jul 10, 2020 at 06:01:58PM +0900, Masahiko Sawada wrote: > >> >On Fri, 3 Jul 2020 at 09:58, Tomas Vondra <

Re: Default setting for enable_hashagg_disk

David Rowley writes: > hmm yeah. It's unfortunate, but I'm not sure how I'd have implemented > it differently. The problem is made worse by the fact that we'll only > release the memory for the hash table during ExecEndHashJoin(). If the > planner had some ability to provide the executor with kno

Re: min_safe_lsn column in pg_replication_slots view

Alvaro Herrera writes: > On 2020-Jul-09, Alvaro Herrera wrote: >> I think we should define InvalidXLogSegNo to be ~((uint64)0) and add a >> macro to test for that. > That's overkill really. I just used zero. Running > contrib/test_decoding under valgrind, this now passes. > I think I'd rather

Re: Default setting for enable_hashagg_disk

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I don't see hash_mem as being any kind of proper fix- it's just punting > > to the user saying "we can't figure this out, how about you do it" and, > > worse, it's in conflict with how we already ask the user that quest

Re: Binary support for pgoutput plugin

Petr Jelinek writes: > On 11/07/2020 14:14, Dave Cramer wrote: >> So is there any point in having them as options then ? > I am guessing this is copied from pglogical, right? We have them there > because it can optionally send data in the on-disk format (not the > network binary format) and the

Re: Binary support for pgoutput plugin

Hi, On 11/07/2020 14:14, Dave Cramer wrote: On Fri, 10 Jul 2020 at 14:21, Tom Lane > wrote: > Reading through the new patch, and running the tests, I'm marking this as Ready > for Committer.  It does need some cosmetic TLC, quite possibly just fro

Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away

Thanks for the comments. Attaching the v2 patch. > > > One way, we could solve the above problem is that, upon firing the new > > foreign query from local backend using the cached connection, > > (assuming the remote backend that was cached in the local backed got > > killed for some reasons), ins

Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM

On Tue, Jun 30, 2020 at 2:41 PM Bharath Rupireddy wrote: > > Thanks Vignesh and Rushabh for reviewing this. > > I've added this patch to commitfest - https://commitfest.postgresql.org/28/. I felt this patch is ready for committer, changing the status to ready for committer. Regards, Vignesh Ente

Re: Include access method in listTables output

On Mon, Jul 6, 2020 at 1:24 PM Georgios wrote: > > > > ‐‐‐ Original Message ‐‐‐ > On Monday, July 6, 2020 3:12 AM, Michael Paquier wrote: > > > On Sun, Jul 05, 2020 at 07:13:10AM +0530, vignesh C wrote: > > > > > I'm not sure if we should include showViews, I had seen that the > > > acces

INSERT INTO SELECT, Why Parallelism is not selected?

I have just notice that the parallelism is off even for the select part of the query mentioned in the $subject. I see the only reason it is not getting parallel because we block the parallelism if the query type is not SELECT. I don't see any reason for not selecting the parallelism for this quer

Re: Binary support for pgoutput plugin

On Fri, 10 Jul 2020 at 14:21, Tom Lane wrote: > Daniel Gustafsson writes: > > Thanks for the update! Do note that my patch included a new file which > is > > missing from this patchset: > > src/test/subscription/t/014_binary.pl > > This is, IMO, the most interesting test of this feature s

Re: [PATCH] pg_dump: Add example and link for --encoding option

On 2020-06-05 14:45, 이동욱 wrote: I've modified my previous patch because it linked the wrong document so I fixed it. and I add a highlight to the encoding list for readability. What do you think about this change? The wording in your patch needed a bit of editing but adding a link to the supp

Re: WIP: BRIN multi-range indexes

On Fri, Jul 10, 2020 at 04:44:41PM +0200, Sascha Kuhl wrote: Tomas Vondra schrieb am Fr., 10. Juli 2020, 14:09: On Fri, Jul 10, 2020 at 06:01:58PM +0900, Masahiko Sawada wrote: >On Fri, 3 Jul 2020 at 09:58, Tomas Vondra wrote: >> >> On Sun, Apr 05, 2020 at 08:01:50PM +0300, Alexander Korotkov

Re: output columns of \dAo and \dAp

On Fri, Jul 10, 2020 at 2:24 AM Alexander Korotkov wrote: > On Thu, Jul 9, 2020 at 10:03 PM Jonathan S. Katz wrote: > > From the RMT perspective, if there is an agreed upon approach (which it > > sounds like from the above) can someone please commit to working on > > resolving this open item? > >

Re: Wait profiling

On Fri, Jul 10, 2020 at 10:37 PM Alvaro Herrera wrote: > > On 2020-Jul-10, Daniel Wood wrote: > > > After nearly 5 years does something like the following yet exist? > > https://www.postgresql.org/message-id/559d4729.9080...@postgrespro.ru > > Yes, we have pg_stat_activity.wait_events which implem