Re: [HACKERS] libpq Alternate Row Processor

On 2/13/17 8:46 AM, Kyle Gearhart wrote: profile_filler.txt 61,410,901 ???:_int_malloc [/usr/lib64/libc-2.17.so] 38,321,887 ???:_int_free [/usr/lib64/libc-2.17.so] 31,400,139 ???:pqResultAlloc [/usr/local/pgsql/lib/libpq.so.5.10] 22,839,505 ???:pqParseInput3

Re: [HACKERS] Should we cacheline align PGXACT?

Alexander Korotkov wrote: > On Tue, Feb 14, 2017 at 3:57 PM, Alvaro Herrera > wrote: > > Yes, I understand. I just mean that it could be done something like > > this: > > > > #define PGXACTPadSize (PG_CACHE_LINE_SIZE - (offsetof(PGXACT, nxid) + > > sizeof(uint8))) > >

Re: [HACKERS] Sum aggregate calculation for single precsion real

On 2/13/17 10:45 AM, Konstantin Knizhnik wrote: It is not true - please notice query execution time of this two queries: I bet you'd get even less difference if you simply cast to float8 instead of adding 0.0. Same result, no floating point addition. The expectation for SUM(float4) is that

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

On Tue, Feb 14, 2017 at 8:15 AM, Fabien COELHO wrote: >> I believe that what was agreed was to eliminate "xlog" from >> user-facing parts of the system, not internal details. [...] > Ok, I get it. So xlog stays xlog if it is hidden from the user, eg file > names and probably

Re: [HACKERS] removing tsearch2

On 2/13/17 2:37 AM, Magnus Hagander wrote: That's based on an assumption that PGXN shouldn't be treated as part of the community effort, which I think is a mistake. Having a robust, community run extension/package/module framework has proven to be extremely valuable for other

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

I believe that what was agreed was to eliminate "xlog" from user-facing parts of the system, not internal details. [...] Ok, I get it. So xlog stays xlog if it is hidden from the user, eg file names and probably unexposed functions names, structures or whatever, but everything else has been

Re: [HACKERS] Should we cacheline align PGXACT?

On Tue, Feb 14, 2017 at 3:57 PM, Alvaro Herrera wrote: > Alexander Korotkov wrote: > > On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > Re the coding of the padding computation, seems it'd be better to use > > > our

Re: [HACKERS] Should we cacheline align PGXACT?

Alexander Korotkov wrote: > On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera > wrote: > > Re the coding of the padding computation, seems it'd be better to use > > our standard "offsetof(last-struct-member) + sizeof(last-struct-member)" > > rather than adding each of the

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

On Tue, Feb 14, 2017 at 2:45 AM, Fabien COELHO wrote: >> You may want to name the new headers dedicated to WAL records with _xlog.h >> as suffix though, like gin_xlog.h instead of ginxlog.h. > > Should not it be more consistent to use "*_wal.h", after all these efforts > to

Re: [HACKERS] LWLock optimization for multicore Power machines

On Mon, Feb 13, 2017 at 10:17 PM, Tomas Vondra wrote: > On 02/13/2017 03:16 PM, Bernd Helmle wrote: > >> Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov: >> >>> Thus, I see reasons why in your tests absolute results are lower than >>> in my >>>

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

On Tue, Feb 14, 2017 at 12:23 AM, Michael Paquier wrote: > On Tue, Feb 14, 2017 at 12:42 PM, Robert Haas wrote: >> Therefore, I proposed the attached patch, which splits spgxlog.h out >> of spgist_private.h, nbtxlog.h out of nbtree.h, gistxlog.h

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Jan 9, 2017 at 8:32 PM, Anastasia Lubennikova wrote: > Updated version of the patch is attached. Besides code itself, it contains > new regression test, > documentation updates and a paragraph in nbtree/README. > The latest patch doesn't apply cleanly. Few

Re: [HACKERS] Should we cacheline align PGXACT?

On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera wrote: > Alexander Korotkov wrote: > > > Yes, influence seems to be low. But nevertheless it's important to > insure > > that there is no regression here. > > Despite pg_prewarm'ing and running tests 300s, there is still

Re: [HACKERS] Proposal : Parallel Merge Join

On Tue, Feb 14, 2017 at 12:25 PM, Amit Kapila wrote: > Few review comments on the latest version of the patch: > 1. > - if (joinrel->consider_parallel && nestjoinOK && > - save_jointype != JOIN_UNIQUE_OUTER && > - bms_is_empty(joinrel->lateral_relids)) > + if

Re: [HACKERS] Measuring replay lag

On 14 February 2017 at 11:48, Thomas Munro wrote: > Here is a new version with the buffer on the sender side as requested. Thanks, I will definitely review in good time to get this in PG10 -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Measuring replay lag

On Wed, Feb 1, 2017 at 5:21 PM, Michael Paquier wrote: > On Sat, Jan 21, 2017 at 10:49 AM, Thomas Munro > wrote: >> Ok. I see that there is a new compelling reason to move the ring >> buffer to the sender side: then I think lag tracking

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Thank you for the comment. At Mon, 6 Feb 2017 17:10:43 +0100, Pavel Stehule wrote in > > 0001-Refactoring-tab-complete-to-make-psql_completion-cod.patch > > - Just a refactoring of psql_completion >

[HACKERS] PostgreSQL Code of Conduct Draft

The revised draft of the proposed Code of Conduct for the PostgreSQL community is at https://wiki.postgresql.org/wiki/Code_of_Conduct. This updated draft incorporates comments and suggestions from the community received at PgCon Ottawa and subsequent discussion. We will not be monitoring the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

For two states: * for being executed (beware, it is ***important***) It does lend importance, but that's also the line continuation marker for "comment". Would that be a problem? Argh. Indeed, even if people seldom type C comments in psql interactive mode... Remaining ASCII characters

Re: [HACKERS] Small improvement to parallel query docs

On 14 February 2017 at 21:25, Amit Kapila wrote: > +Aggregate stage. For such cases there is clearly going to be no > +performance benefit to using parallel aggregation. > > A comma is required after "For such cases" Added >> The query planner takes >> +this

[HACKERS] Sync message

Sync message causes backend to return a "Ready for query" response even if there's no query previously sent to the backend. I don't think this is a bug but I'd think it would be better to write this behavior in the doc, because it might help someone who want to write an API which needs to handle

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Tue, Feb 14, 2017 at 11:49 AM, Seki, Eiji wrote: > Hi all, > > I propose the patch that adds a function GetOldestXminExtended that is like > GetOldestXmin but can ignore arbitrary vacuum flags. And then, rewrite > GetOldestXmin to use it. Note that this is done so

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > @in't gonna execute it? >> > > Hmmm... This is too much of an Americanism, IMHO. The @ looks like a handwritten 'a'. @in't gonna => ain't gonna => will not. It's a bad joke, made as a way of saying that I also could not think of a good mnemonic for '@' or ','. > I'm here all week, try the

Re: [HACKERS] parallelize queries containing subplans

On Tue, Jan 3, 2017 at 4:19 PM, Amit Kapila wrote: > On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote: >> >> Now, we can further extend this to parallelize queries containing >> correlated subplans like below: >> >> explain select * from t1

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Michael Paquier wrote: > It seems to me that it would be far less confusing to just replace the > boolean argument of GetOldestXmin by a uint8 and get those flags declared in > procarray.h, no? There are a couple of code path calling > GetOldestXmin() that do not

Re: [HACKERS] possibility to specify template database for pg_regress

2017-02-14 3:36 GMT+01:00 Andres Freund : > On 2017-02-13 20:59:43 +0100, Pavel Stehule wrote: > > Hi > > > > 2017-02-13 6:46 GMT+01:00 Michael Paquier : > > > > > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule < > pavel.steh...@gmail.com> > > >

Re: [HACKERS] Small improvement to parallel query docs

On Tue, Feb 14, 2017 at 3:33 AM, David Rowley wrote: > On 14 February 2017 at 10:56, Brad DeJong wrote: >> David Rowley wrote: >>> I propose we just remove the whole paragraph, and mention about >>> the planning and estimated number of groups

<    1   2