Re: [HACKERS] asynchronous and vectorized execution

On 21 July 2016 at 15:20, Kyotaro HORIGUCHI wrote: > > After some consideration, I found that ExecAsyncWaitForNode > cannot be reentrant because it means that the control goes into > async-unaware nodes while having not-ready nodes, that is > inconsistent state.

Re: [HACKERS] Broken order-of-operations in parallel query latch manipulation

On Mon, Aug 1, 2016 at 1:58 AM, Tom Lane wrote: > Both shm_mq.c and nodeGather.c contain instances of this coding pattern: > > WaitLatch(MyLatch, WL_LATCH_SET, 0); > CHECK_FOR_INTERRUPTS(); > ResetLatch(MyLatch); > > I believe this is wrong

Re: [HACKERS] Combining hash values

On Mon, Aug 1, 2016 at 4:34 AM, Tom Lane wrote: > Thomas Munro writes: >> 2. I suspect that this algorithm for combining hashes is weak, and >> could amplify weaknesses in the hash functions feeding it. > > Very possibly, but ... Concrete

Re: [HACKERS] Slowness of extended protocol

Andres Freund writes: > FWIW, I've observed the same with (a bit) more complicated queries. A > part of this is that the extended protocol simply does > more. PQsendQueryGuts() sends Parse/Bind/Describe/Execute/Sync - that's > simply more work and data over the wire than a

Re: [HACKERS] Slowness of extended protocol

On 2016-07-31 22:26:00 +0100, Greg Stark wrote: > I think you're looking at this the wrong way around. 30% of what? > You're doing these simple read-only selects on a database that > obviously is entirely in RAM. If you do the math on the numbers you > gave above the simple protocol took 678

Re: [HACKERS] Slowness of extended protocol

On Sun, Jul 31, 2016 at 4:05 PM, Shay Rojansky wrote: > I'm well aware of how the extended protocol works, but it seems odd for a > 30% increase in processing time to be the result exclusively of processing 5 > messages instead of just 1 - it doesn't seem like that big a deal

[HACKERS] Broken order-of-operations in parallel query latch manipulation

Both shm_mq.c and nodeGather.c contain instances of this coding pattern: WaitLatch(MyLatch, WL_LATCH_SET, 0); CHECK_FOR_INTERRUPTS(); ResetLatch(MyLatch); I believe this is wrong and the CHECK_FOR_INTERRUPTS needs to be before or after the two latch

Re: [HACKERS] Hash indexes and effective_cache_size in CREATE INDEX documentation

On Sun, Jul 31, 2016 at 10:05 AM, Tom Lane wrote: > After looking at that a bit, I'm strongly tempted to just take out > the last two sentences of the para, reducing it to the advice concerning > maintenance_work_mem. That seems sufficient to describe the current > behavior,

Re: [HACKERS] Hash indexes and effective_cache_size in CREATE INDEX documentation

I wrote: > Peter Geoghegan writes: >> The CREATE INDEX documentation states: >> "For hash indexes, the value of effective_cache_size is also relevant >> to index creation time: PostgreSQL will use one of two different hash >> index creation methods depending on whether the

Re: [HACKERS] Slowness of extended protocol

> > Shay Rojansky : > >> I'm well aware of how the extended protocol works, but it seems odd for a >> 30% increase in processing time to be the result exclusively of processing >> 5 messages instead of just 1 - it doesn't seem like that big a deal >> (although I may be mistaken). I

Re: [HACKERS] Combining hash values

Thomas Munro writes: > 2. I suspect that this algorithm for combining hashes is weak, and > could amplify weaknesses in the hash functions feeding it. Very possibly, but ... > Compare > Boost's hash_combine, which does some more work before XORing: > seed ^=

Re: [HACKERS] Hash indexes and effective_cache_size in CREATE INDEX documentation

Peter Geoghegan writes: > The CREATE INDEX documentation states: > "For hash indexes, the value of effective_cache_size is also relevant > to index creation time: PostgreSQL will use one of two different hash > index creation methods depending on whether the estimated index size

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 07/30/2016 04:47 PM, Tom Lane wrote: Pavel Stehule writes: But there are some patterns used with work with temp tables,that should not working, and we would to decide if we prepare workaround or not. -- problematic pattern (old code) IF NOT EXISTS(SELECT * FROM

Re: [HACKERS] Syntax of xmltable function

Pavel Stehule writes: > The SQL/XML syntax is: > XMLTABLE ( > xmlquery > PASSING xmldocument > [COLUMNS columns_list] ) > columns_list := column_list ',' colname > colname := colname datatype [DEFAULT value] [PATH text] > The DEFAULT clause is before PATH

Re: [HACKERS] Slowness of extended protocol

Shay Rojansky : > I'm well aware of how the extended protocol works, but it seems odd for a > 30% increase in processing time to be the result exclusively of processing > 5 messages instead of just 1 - it doesn't seem like that big a deal > (although I may be mistaken). I was

Re: [HACKERS] Slowness of extended protocol

> > Without re-using prepared statements or portals, extended protocol is > always slow because it requires more messages exchanges than simple > protocol. In pgbench case, it always sends parse, bind, describe, > execute and sync message in each transaction even if each transaction > involves

Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Sat, Jul 30, 2016 at 5:47 AM, Stephen Frost wrote: > > What we need to be doing here is combining the set of components that > > the sequence has been marked with and the set of components that the > > table

Re: [HACKERS] Slowness of extended protocol

> Hi all. I know this has been discussed before, I'd like to know what's the > current position on this. > > Comparing the performance of the simple vs. extended protocols with pgbench > yields some extreme results: > > $ ./pgbench -T 10 -S -M simple -f /tmp/pgbench.sql pgbench > tps =

[HACKERS] Slowness of extended protocol

Hi all. I know this has been discussed before, I'd like to know what's the current position on this. Comparing the performance of the simple vs. extended protocols with pgbench yields some extreme results: $ ./pgbench -T 10 -S -M simple -f /tmp/pgbench.sql pgbench tps = 14739.803253 (excluding

[HACKERS] Syntax of xmltable function

Hi I am working on xmltable function. This function is used for simple data extraction from XML documents. In this moment I am working on prototype's parser. The SQL/XML syntax is: XMLTABLE ( xmlquery PASSING xmldocument [COLUMNS columns_list] ) columns_list := column_list ',' colname

[HACKERS] programming libraries - collection of hash-fuctions and indexes for all situations from dbms till 3d-graphics?

hi, can you prompt a programming libraries - collection of hash-fuctions and indexes for all situations from dbms till 3d-graphics?