Re: wal_dump output on CREATE DATABASE

Le jeu. 15 nov. 2018 à 19:44, Robert Haas a écrit : > On Tue, Nov 13, 2018 at 3:40 PM Tomas Vondra > wrote: > > People reading pg_waldump output quickly learn to read the A/B/C format > > and what those fields mean. Breaking that into ts=A db=B relfilenode=C > > does not make that particularly

Re: wal_dump output on CREATE DATABASE

On 11/16/18 12:05 PM, Jean-Christophe Arnu wrote: Le jeu. 15 nov. 2018 à 19:44, Robert Haas > a écrit : On Tue, Nov 13, 2018 at 3:40 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote: > People reading pg_waldump output quickly learn

Re: Speeding up INSERTs and UPDATEs to partitioned tables

One thing I don't quite like is the inconsistency in handling memory context switches in the various function allocating stuff. It seems rather haphazard. I'd rather have a memcxt member in PartitionTupleRouting, which is set when the struct is created, and then have all the other functions

Re: [PATCH] Opclass parameters

В письме от 15 ноября 2018 18:26:43 пользователь Nikita Glukhov написал: > >> But since it is now "Rejected with feedback", let's wait till autumn. > > > > We don't want to wait that long. But now we only need to сome to an > > agreement > > about CREATE INDEX syntax and where to store the

Re: wal_dump output on CREATE DATABASE

On Fri, Nov 16, 2018 at 12:05:00PM +0100, Jean-Christophe Arnu wrote: > As I said, I don't know whether it's relevant to perform these changes or > not. If the A/B/C notation is to be generalized, it would be worth document > it > in the SGML file. If not, the first patch provided should be

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Fri, Nov 16, 2018 at 9:43 AM Haribabu Kommi wrote: > > On Thu, Nov 15, 2018 at 5:18 PM Amit Kapila wrote: >> >> > +-- >> > +-- remove query ('SELECT $1 + $2 AS "TWO"') executed by >> > regress_stats_user2 in the current_database >> > +-- >> > +SELECT pg_stat_statements_reset((SELECT r.oid

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

> > My main comment is that the description of the purpose of the GUC doesn't > > help me understand when or why I might want to alter it from the default > > value. If nobody is going to alter it, because nobody understands it, it > > might as well remain a compile-time constant. > > Yeah, that's

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Fri, 16 Nov 2018 at 14:00, James Coleman wrote: > > > My main comment is that the description of the purpose of the GUC > doesn't > > > help me understand when or why I might want to alter it from the > default > > > value. If nobody is going to alter it, because nobody understands it, > it >

Re: pg11.1 jit segv

On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > I'm about to commit some changes to 12/master that'd possibly make it > easier to find issues like this. Are you referring to this a future commit ? commit 763f2edd92095b1ca2f4476da073a28505c13820 Rejigger materializing and

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Thu, Nov 15, 2018 at 8:58 PM Amit Langote wrote: > The partition_bounds_copy() is not because of your changes, it's there in > HEAD. OK, but it seems to me that your version of my patch rearranges the code more than necessary. How about the attached? -- Robert Haas EnterpriseDB:

Re: pg11.1 jit segv

Hi, On 2018-11-16 08:38:26 -0600, Justin Pryzby wrote: > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > > I'm about to commit some changes to 12/master that'd possibly make it > > easier to find issues like this. > > Are you referring to this a future commit ? > commit

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018-Nov-16, Alvaro Herrera wrote: > One thing I don't quite like is the inconsistency in handling memory > context switches in the various function allocating stuff. It seems > rather haphazard. I'd rather have a memcxt member in > PartitionTupleRouting, which is set when the struct is

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote: > Are you referring to this a future commit ? this OR a future commit > The table is not too special, but was probably ALTERed to add columns a good > number of times by one of our processes. It has ~1100 columns, including >

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

I wrote: > Are we sufficiently convinced that we must have the dont-allow-partial > option to not fix this in the back branches? I'm not. I just had a thought about that: suppose we add a flag to CopyState to indicate whether we reached EOF while reading. This wouldn't be hugely expensive, just

Re: Libpq support to connect to standby server as priority

Tom Lane wrote: > > As it is now, the patch doesn't keep two connections open. It remembers > > the index of the host of the first successful writable connection, but > > closes the connection, and opens another one to that host if no read-only > > host can be found. > > Oh! The reason I

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018-Nov-13, David Rowley wrote: > The 0002 patch is included again, this time with a new proposed commit > message. There was some discussion over on [1] where nobody seemed to > have any concerns about delaying the locking until we route the first > tuple to the partition. Please get a new

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Simon Riggs writes: > On Fri, 16 Nov 2018 at 14:00, James Coleman wrote: >>> Yeah, that's sort of my reaction as well. I also feel like this is a >>> mighty special case to expose as a separate GUC. There are other magic >>> effort-limiting constants elsewhere in the planner --- we just added

Re: wal_dump output on CREATE DATABASE

Le ven. 16 nov. 2018 à 14:32, Tomas Vondra a écrit : > > > > appendStringInfo(buf, "xid %u (db/rel) %u/%u ", > > xlrec->locks[i].xid, xlrec->locks[i].dbOid, > > xlrec->locks[i].relOid); > > > > > > As I said, I don't know whether it's

Re: Speeding up INSERTs and UPDATEs to partitioned tables

I repeated David's original tests not terribly rigorously[*] and got these numbers: * Unpatched:72.396196 * 0001 :77.279404 * 0001+0002: 20409.415094 * 0002: 816.606613 * control : 22969.140596 (insertion into unpartitioned table) So while this patch by itself gives a pretty

Re: Constraint documentation

I set this patch waiting-on-author. Please update. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

>> I'd be happy to yank this in favor of my holistic solution to this >> problem I posted recently on the mailing list [1]. > > [1] > https://www.postgresql.org/message-id/flat/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg%40mail.gmail.com > > Not precisely sure what you mean - are you

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Robert Haas writes: > On Thu, Nov 15, 2018 at 5:50 PM Tom Lane wrote: >> There have been occasional discussions of inventing a master "planner >> effort" control knob, with values say 1..10 [1], and allowing that one >> thing to control all these decisions, as well as other things we might do >>

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote: > BTW find attached patch which I believe corrects some comments. Updated. Some of the changes may be gratuitous, but changed while I was already looking. Also note that I had to remove -flto=thin to compile under RH7. Justin diff

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Thu, Nov 15, 2018 at 5:50 PM Tom Lane wrote: > There have been occasional discussions of inventing a master "planner > effort" control knob, with values say 1..10 [1], and allowing that one > thing to control all these decisions, as well as other things we might do > in the future that would

Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Fri, Nov 16, 2018 at 10:11 AM Tom Lane wrote: > I don't think so, because right now they (a) can't get either > optimization, and/or (b) don't know what either one does or > how to invoke it. Sure. But as soon as they know that, they're just going to try to figure out how to get the thing

Re: Libpq support to connect to standby server as priority

Laurenz Albe writes: > Tom Lane wrote: >> I don't like this patch at all: the business with keeping two connections >> open seems impossibly fragile and full of race conditions. > As it is now, the patch doesn't keep two connections open. It remembers > the index of the host of the first

Re: Index Skip Scan

Hi, On 11/15/18 6:41 AM, Alexander Kuzmenkov wrote: But having this logic inside _bt_next means that it will make a non-skip index only scan a bit slower, am I right? Correct. Well, it depends on how the skip scan is implemented. We don't have to make normal scans slower, because skip

Re: Optimze usage of immutable functions as relation

Aleksandr Parfenov writes: > [ funcscan_plan_optimizer_v4.patch ] A small note here --- this would be noticeably cleaner if removal of the no-longer-needed function RTE were done using the dummy-relation infrastructure I proposed in https://commitfest.postgresql.org/20/1827/ Maybe we should

Re: Refactoring the checkpointer's fsync request queue

On Thu, Nov 15, 2018 at 5:09 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > While testing this patch with frequent checkpoints I've stumbled upon an > interesting error, that happened already after I finished one test: > > TRAP: FailedAssertion("!(rc > 0)", File: "checkpointer.c", Line: 574)

Re: [HACKERS] pgbench - allow to store select results into variables

On 2017-Nov-04, Fabien COELHO wrote: > Think of one initialization followed by two appends: > > SELECT 1 AS x \cset > SELECT 2 \; SELECT 3 AS y \cset > SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset > > In the end, we must have the full 6 queries > > "SELECT 1 AS x \; SELECT 2 \; SELECT 3

Another limitation of built-in logical replication

Folks, At least two external logical replication systems have simple ways to change the node which is accepting rights for a replication set. Please find attached a doc patch naming the lack of this feature as a current limitation. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415

Re: Early WIP/PoC for inlining CTEs

Andreas Karlsson writes: > [ inlining-ctes-v5.patch ] I took a little bit of a look through this. Some thoughts: * I think it'd be a good idea if we made OFFSET/LIMIT in a CTE be an alternate way of keeping it from being inlined. As the patch stands, if that's the behavior you want, you have

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

I wrote: > I just had a thought about that: suppose we add a flag to CopyState > to indicate whether we reached EOF while reading. ... > Then the logic in ClosePipeToProgram could be "if we did not reach > EOF, then a SIGPIPE termination is unsurprising. If we did reach > EOF, then SIGPIPE is an

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

On 2018-Sep-05, Marina Polyakova wrote: > v11-0001-Pgbench-errors-use-the-RandomState-structure-for.patch > - a patch for the RandomState structure (this is used to reset a client's > random seed during the repeating of transactions after > serialization/deadlock failures). Pushed this one with

Re: Refactoring the checkpointer's fsync request queue

On Sat, Nov 17, 2018 at 4:05 AM Robert Haas wrote: > On Wed, Nov 14, 2018 at 4:49 PM Andres Freund wrote: > > On 2018-11-14 16:36:49 -0500, Robert Haas wrote: > > > But how do you make reading that counter atomic with the open() itself? > > > > I don't see why it has to be. As long as the "fd

Re: Early WIP/PoC for inlining CTEs

On Fri, Nov 16, 2018 at 04:15:10PM -0500, Tom Lane wrote: > Andreas Karlsson writes: > > [ inlining-ctes-v5.patch ] > > I took a little bit of a look through this. Some thoughts: > > * I think it'd be a good idea if we made OFFSET/LIMIT in a CTE be an > alternate way of keeping it from being

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

Etsuro Fujita writes: > * I think it's better to ignore the SIGPIPE failure in > ClosePipeToProgram if we were in a COPY FROM PROGRAM that was allowed to > terminate early and keep the behavior as-is otherwise. If we ignore > that failure unconditionally in that function, eg, COPY TO PROGRAM

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

Etsuro Fujita writes: > [ fix-foreign-modify-efujita-2.patch ] Um ... wow, I do not like anything about this. Adding a "tableoid = X" constraint to every remote update query seems awfully expensive, considering that (a) it's useless for non-partitioned tables, and (b) the remote planner will

Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE

Thanks for the quick responses. I've put some inline follow-up questions. On a separate note, I had one additional code clarity feedback. I felt that eqjoinsel could be reorganized a bit for readability/clarity for the reader. For example, eqjoinsel_inner uses only the AttStatsSlots up until here

Re: zheap: a new storage format for PostgreSQL

On Thu, Nov 1, 2018 at 12:13 PM Amit Kapila wrote: > > > Now, we have a working solution for this problem. The extended > transaction slots are stored in TPD pages (those contains only > transaction slot arrays) which are interleaved with regular pages. > For a detailed idea, you can see atop

Re: zheap: a new storage format for PostgreSQL

> I don't know how much what I write on this thread is read by others or how useful this is for others who are following this work I've been following this thread and many others like it, silently soaking it up, because I don't feel like i'd have anything useful to add in most cases. It is very

Re: zheap: a new storage format for PostgreSQL

On Sat, Nov 17, 2018 at 11:21 AM Adam Brusselback wrote: > > > I don't know how much what I write on this thread is read by others or > how useful this is for others who are following this work > > I've been following this thread and many others like it, silently soaking it > up, because I

Re: TupleTableSlot abstraction

Hi, On 2018-11-13 15:30:21 -0800, Andres Freund wrote: > What I'm now planning to do is to go through the big comment in > tuptable.h and update that to the new world. While I'm not convinced > that that that's the best place for it, it needs to be accurate. > > Furthermore: > - More comment

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

On Sat, Nov 17, 2018 at 5:56 AM Tom Lane wrote: > Thomas Munro writes: > > [ 0001-Add-WL_EXIT_ON_PM_DEATH-pseudo-event-v4.patch ] > > I took a quick look through this. I have no objection to the idea of > letting the latch infrastructure do the proc_exit(1), but I'm wondering > why this is in

Re: pg11.1 jit segv

Hi, On 2018-11-16 19:23:44 -0600, Justin Pryzby wrote: > On Fri, Nov 16, 2018 at 08:29:27AM -0800, Andres Freund wrote: > > > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > > > > I'm about to commit some changes to 12/master that'd possibly make it > > commit

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Fri, Nov 16, 2018 at 11:00 PM Amit Kapila wrote: > On Fri, Nov 16, 2018 at 9:43 AM Haribabu Kommi > wrote: > > > > On Thu, Nov 15, 2018 at 5:18 PM Amit Kapila > wrote: > >> > >> > +-- > >> > +-- remove query ('SELECT $1 + $2 AS "TWO"') executed by > >> > regress_stats_user2 in the

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Fri, Nov 16, 2018 at 09:38:40AM -0500, Robert Haas wrote: > OK, but it seems to me that your version of my patch rearranges the > code more than necessary. > > How about the attached? What you are proposing here looks good to me. Thanks! -- Michael signature.asc Description: PGP signature

Re: Libpq support to connect to standby server as priority

On Sat, Nov 17, 2018 at 10:41:54AM +1100, Haribabu Kommi wrote: > Yes, we need either session open or reconnect it approach to find out > the whether server is read-write or read-only. Even if there is no agreement on this part, wouldn't a read-only option be enough to support any case? With a

Re: Why do pg_upgrade's test use the serial schedule? (actual thread)

Hi, I unfortunately copied the wrong message id into a bunch of commit messages, and just noticed now. Messages pointing to this message's parent via: Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5b...@alap3.anarazel.de ought to have been Discussion:

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Sat, Nov 17, 2018 at 4:47 AM Haribabu Kommi wrote: > > With the above query to get the queryid, but there are no such queries > present in the pg_stat_statements, so the above query returns NULL as > output, and with NULL as input to the _reset() function, it takes the default > value of 0,

Re: Early WIP/PoC for inlining CTEs

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> * I have no faith in the idea that we can skip doing a copyObject > Tom> on the inlined subquery, except maybe in the case where we know > Tom> there's exactly one reference. > The code doesn't do a copyObject on the query if there are

Re: Early WIP/PoC for inlining CTEs

> "Tom" == Tom Lane writes: >> [ inlining-ctes-v5.patch ] Tom> I took a little bit of a look through this. Some thoughts: Tom> * I think it'd be a good idea if we made OFFSET/LIMIT in a CTE be Tom> an alternate way of keeping it from being inlined. As the patch Tom> stands, if that's

Re: Libpq support to connect to standby server as priority

On Sat, Nov 17, 2018 at 4:56 AM Laurenz Albe wrote: > Tom Lane wrote: > > > As it is now, the patch doesn't keep two connections open. It > remembers > > > the index of the host of the first successful writable connection, but > > > closes the connection, and opens another one to that host if

Re: pg11.1 jit segv

On Fri, Nov 16, 2018 at 08:29:27AM -0800, Andres Freund wrote: > > On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote: > > > I'm about to commit some changes to 12/master that'd possibly make it > commit 15d8f83128e15de97de61430d0b9569f5ebecc26 I don't think it had to do with your

Re: Early WIP/PoC for inlining CTEs

Greetings, * Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > > "Tom" == Tom Lane writes: > > >> [ inlining-ctes-v5.patch ] > > Tom> I took a little bit of a look through this. Some thoughts: > > Tom> * I think it'd be a good idea if we made OFFSET/LIMIT in a CTE be > Tom> an

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

I wrote: > I'm not quite sure whether the reached_eof test should be > "if (bytesread == 0)" or "if (bytesread < maxread)". The former > seems more certain to indicate real EOF; are there other cases where > the fread might return a short read? On the other hand, if we > support in-band EOF

Re: Refactoring the checkpointer's fsync request queue

On Wed, Nov 14, 2018 at 4:49 PM Andres Freund wrote: > On 2018-11-14 16:36:49 -0500, Robert Haas wrote: > > But how do you make reading that counter atomic with the open() itself? > > I don't see why it has to be. As long as the "fd generation" assignment > happens before fsync (and writes

Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE

Melanie Plageman writes: > This patch applies cleanly and works for the case described in the original > email. All existing regression tests pass with the addition of the explain > plan > update included in the patch. Thanks for reviewing! > I could not devise an example in which the

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

Thomas Munro writes: > [ 0001-Add-WL_EXIT_ON_PM_DEATH-pseudo-event-v4.patch ] I took a quick look through this. I have no objection to the idea of letting the latch infrastructure do the proc_exit(1), but I'm wondering why this is in the thread that it's in. Is there any remaining connection