Re: heads up: Fix for intel hardware bug will lead to performance regressions

On 2018-01-08 14:38:20 +1300, Thomas Munro wrote: > Just an idea, not sure if it's worth looking into; maybe we already > spend enough time filling those buffers that a 50% syscall markup > won't hurt. Yea, I suspect that won't make a huge difference - copying an 8kb buffer is typically a lot more

Re: [HACKERS] Statement-level rollback

On 6 November 2017 at 12:36, MauMau wrote: > when I submit the next revision of my patch. When will the next version be posted? -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Logical decoding fast-forward and slot advance

On 31 December 2017 at 10:44, Petr Jelinek wrote: > Attached is patch which adds ability to do fast-forwarding while > decoding. That means wal is consumed as fast as possible and changes are > not given to output plugin for sending. The implementation is less > invasive than I originally though

Re: Parallel append plan instability/randomness

Amit Khandekar writes: > The fact that b_star gets moved from 5th position to the first > position in the scans, indicates that it's cost shoots up from 1.04 to > a value greater than 1.16. It does not look like a case where two > costs are almost same due to which their positions swap sometimes.

Re: Parallel append plan instability/randomness

On 8 January 2018 at 10:10, Amit Kapila wrote: > regression=# explain select round(avg(aa)), sum(aa) from a_star; > QUERY PLAN > --- > Finalize Aggregate (cost=2.30..2.31 rows=1 width=40

Re: heads up: Fix for intel hardware bug will lead to performance regressions

On Mon, Jan 8, 2018 at 1:32 PM, Thomas Munro wrote: > Also pgarch.c, syncrep.c, walsender.c and walreceiver.c use > PostmasterIsAlive() every time through their loops[1] generating extra > syscalls, one instance of which has caused complaints before[1] on a > system where the syscall was expensive

Re: Parallel append plan instability/randomness

On Sun, Jan 7, 2018 at 5:44 AM, Tom Lane wrote: > According to buildfarm member silverfish, > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=silverfish&dt=2018-01-06%2008%3A53%3A38 > > it's possible to sometimes get this failure in the regression tests: > > *** > /mnt/buildfarm/buildro

Re: heads up: Fix for intel hardware bug will lead to performance regressions

On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro wrote: > On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote: >> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote: >>> Note that real-world scenarios probably will see somewhat smaller >>> impact, as this was measured over a loopback unix sockets whi

Re: Enhance pg_stat_wal_receiver view to display connected host

On Fri, Jan 5, 2018 at 11:15 PM, Alvaro Herrera wrote: > Haribabu Kommi wrote: > > > or > > > > write two new functions PQconnhost() and PQconnhostaddr() to return the > > connected host and hostaddr and reuse the PQport() function. > > How about using an API similar to PQconninfo, where we retur

Re: Condition variable live lock

On Sun, Jan 7, 2018 at 10:00 AM, Tom Lane wrote: > I began with the intention of making no non-cosmetic changes, but then > I started to wonder why ConditionVariablePrepareToSleep bothers with a > !proclist_contains test, when the calling process surely ought not be > in the list -- or any other l

Re: Condition variable live lock

Thomas Munro writes: > On Mon, Jan 8, 2018 at 12:38 PM, Tom Lane wrote: >> Concretely, as per attached. > +1 for the idea. Haven't looked at the code yet but I'll review this > and the proclist patch shortly. Thanks. BTW, I realized that there is a second (and perhaps more important) reason w

Re: Condition variable live lock

On Mon, Jan 8, 2018 at 12:38 PM, Tom Lane wrote: > I wrote: >> Actually ... perhaps a better design would be to have >> ConditionVariable[PrepareTo]Sleep auto-cancel any prepared sleep for >> a different condition variable, analogously to what we just did in >> ConditionVariableBroadcast, on the s

Re: heads up: Fix for intel hardware bug will lead to performance regressions

On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote: > On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote: >> Note that real-world scenarios probably will see somewhat smaller >> impact, as this was measured over a loopback unix sockets which'll have >> smaller overhead itself than proper TCP sock

Re: to_timestamp TZH and TZM format specifiers

On 03.01.2018 21:34, Tom Lane wrote: Andrew Dunstan writes: This small and simple standalone patch extracted from the SQL/JSON work would allow the user to supply a string with a time zone specified as hh:mm thus: SELECT to_timestamp('2011-12-18 11:38 -05:20', '-MM-DD HH12:MI TZH

Re: Condition variable live lock

I wrote: > Actually ... perhaps a better design would be to have > ConditionVariable[PrepareTo]Sleep auto-cancel any prepared sleep for > a different condition variable, analogously to what we just did in > ConditionVariableBroadcast, on the same theory that whenever control > returns to the other

Re: [HACKERS] [PATCH] Generic type subscripting

Andres Freund writes: > On 2018-01-07 17:39:00 -0500, Tom Lane wrote: >> Now on the other hand, maybe the right way to go is to embrace a similar >> approach to what I did for plpgsql param eval, and let the datatype >> control what gets generated as the expression execution step. > I'll note tha

Re: [HACKERS] [PATCH] Generic type subscripting

Hi, Tom pointed me towards this thread. I've not followed the topic, so I might miss a bit of context while commenting on expression eval related bits... On 2018-01-07 17:39:00 -0500, Tom Lane wrote: > On the executor side of things, I suspect Andres will be unhappy that > you are making ExprEval

Re: Intermittent crashes on brolga in join.sql test

On 01/07/2018 03:51 PM, Thomas Munro wrote: > Hi Andrew, > > As mentioned over here, but probably lost in the noise of that thread: > > https://www.postgresql.org/message-id/CAEepm%3D2r1svRUfeR1c9Z4UegkPdMw4gxyok4jCWf-h7kdqHHAA%40mail.gmail.com > > ... there is an intermittent crash in my new Par

Re: Expression based aggregate transition / combine function invocation

> Here's a considerably polished variant of this patch. And for realz. >From 3dbc5e9f88ec7d1958b170fa890b7d3d136f709e Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Sun, 7 Jan 2018 14:42:04 -0800 Subject: [PATCH] Expression evaluatation based agg transition invocation. Previously aggregate

Re: Expression based aggregate transition / combine function invocation

Hi, On 2017-11-27 16:31:21 -0800, Andres Freund wrote: > this is part of my work to make expression evaluation JITable. In a lot > of analytics queries the major bottleneck is transition function > invocation (makes sense, hardly anyone wants to see billions of > rows). Therefore for JITing to be

Re: [HACKERS] [PATCH] Generic type subscripting

Dmitry Dolgov <9erthali...@gmail.com> writes: >> On 4 January 2018 at 03:05, Tom Lane wrote: >> I wonder what happened to the plan to separate assignment and fetch into two >> different node types. I can see that that didn't happen so far as primnodes.h >> is concerned, but you've made some change

Re: proposal: alternative psql commands quit and exit

Change my patch will make psql different from other sql clients I use (sqlplus and mysql). I am happy with my custom version of psql so you can cancel/delete/ignore my patch. On Sun, Jan 7, 2018 at 12:36 AM, Tom Lane wrote: > Everaldo Canuto writes: > > Can we proceed with current behavior an

Intermittent crashes on brolga in join.sql test

Hi Andrew, As mentioned over here, but probably lost in the noise of that thread: https://www.postgresql.org/message-id/CAEepm%3D2r1svRUfeR1c9Z4UegkPdMw4gxyok4jCWf-h7kdqHHAA%40mail.gmail.com ... there is an intermittent crash in my new Parallel Hash code that occurs only on your 32 bit Windows X

Re: jsonpath

2018-01-07 21:20 GMT+01:00 Andrew Dunstan : > > > On 01/07/2018 03:16 PM, Pavel Stehule wrote: > > > > > > 2018-01-07 21:14 GMT+01:00 Andrew Dunstan > > mailto:andrew.duns...@2ndquadrant.com > >>: > > > > > > > > On 01/07/2018 03:00 PM, Pavel Stehule wrote: > > > > > > > > > 2018-0

Re: jsonpath

On 01/07/2018 03:16 PM, Pavel Stehule wrote: > > > 2018-01-07 21:14 GMT+01:00 Andrew Dunstan > mailto:andrew.duns...@2ndquadrant.com>>: > > > > On 01/07/2018 03:00 PM, Pavel Stehule wrote: > > > > > > 2018-01-07 20:31 GMT+01:00 Andrew Dunstan > >

Re: jsonpath

2018-01-07 21:14 GMT+01:00 Andrew Dunstan : > > > On 01/07/2018 03:00 PM, Pavel Stehule wrote: > > > > > > 2018-01-07 20:31 GMT+01:00 Andrew Dunstan > > mailto:andrew.duns...@2ndquadrant.com > >>: > > > > > > Next up in the proposed SQL/JSON feature set I will review the three > > jsonpath

Re: jsonpath

On 01/07/2018 03:00 PM, Pavel Stehule wrote: > > > 2018-01-07 20:31 GMT+01:00 Andrew Dunstan > mailto:andrew.duns...@2ndquadrant.com>>: > > > Next up in the proposed SQL/JSON feature set I will review the three > jsonpath patches. These are attached, extracted from the patch set > Nik

Re: jsonpath

2018-01-07 20:31 GMT+01:00 Andrew Dunstan : > > Next up in the proposed SQL/JSON feature set I will review the three > jsonpath patches. These are attached, extracted from the patch set > Nikita posted on Jan 2nd. > > > Note that they depend on the TZH/TZM patch (see separate email thread). > I'd

Re: [PROPOSAL] Shared Ispell dictionaries

On Sun, Dec 31, 2017 at 06:28:13PM +0300, Arthur Zakirov wrote: > > There are issues to do: > - add the GUC-variable for hash table limit > - fix bugs > - improve comments > - performance testing > Here is the second version of the patch. 0002-Retreive-shmem-location-for-ispell-v2.patch: Fixed

Re: WIP: BRIN multi-range indexes

On 12/20/2017 03:37 AM, Mark Dilger wrote: > >> On Dec 19, 2017, at 5:16 PM, Tomas Vondra >> wrote: >> >> >> >> On 12/19/2017 08:38 PM, Mark Dilger wrote: >>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra wrote: Hi, Apparently there was some minor breakage due to d

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Fri, Jan 5, 2018 at 1:39 AM, Robert Haas wrote: > On Tue, Jan 2, 2018 at 1:09 AM, Mithun Cy wrote: >> So in case of N_RELEXTLOCK_ENTS = 1 we can see regression as high 25%. ? Thank you for the performance measurement! > So now the question is: what do these results mean for this patch? > >

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On Sun, Jan 7, 2018 at 9:38 AM, Tom Lane wrote: > ISTM that if this patch gets rid of a large fraction of the uses of > pg_strcasecmp in the backend, which is what I expect it should, then > it might not be out of reach to go through all the surviving ones to > make sure they are not processing st

Re: [HACKERS] Runtime Partition Pruning

On 7 January 2018 at 00:03, David Rowley wrote: > I've fixed this in the attached, but I did so by calling > adjust_appendrel_attrs() from the nodeAppend.c, which did, of course, > mean that the AppendRelInfo needed to be given to the executor. I was > also a bit unsure what exactly I should be do

Re: MCV lists for highly skewed distributions

I wrote: > I'll be travelling for a few days, but I'll do some testing on some > data sets soon. I've attached some preliminary test methods and results. Probably not detailed or rigorous enough, but I wanted to share this much before digging deeper. I created some test data, ran analyze a few ti

Re: [HACKERS] Replication status in logical replication

On 26 December 2017 at 00:26, Masahiko Sawada wrote: > On Tue, Dec 26, 2017 at 1:10 AM, Petr Jelinek > wrote: >> On 21/11/17 22:06, Masahiko Sawada wrote: >>> >>> After investigation, I found out that my previous patch was wrong >>> direction. I should have changed XLogSendLogical() so that we ca

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 30 March 2017 at 13:11, Peter Moser wrote: > 2017-03-01 10:56 GMT+01:00 Peter Moser : >> A similar walkthrough for ALIGN will follow soon. >> >> We are thankful for any suggestion or ideas, to be used to write a >> good SGML documentation. > > The attached README explains the ALIGN operation st

Re: [HACKERS] plpgsql - additional extra checks

Hi 2018-01-07 0:59 GMT+01:00 Stephen Frost : > Greetings Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2017-11-30 3:44 GMT+01:00 Michael Paquier : > > > At least documentation needs patching, or this is going to generate > > > warnings on HEAD at compilation. I am moving this to