On Fri, Nov 10, 2017 at 5:44 AM, Amit Kapila wrote:
> I am seeing the assertion failure as below on executing the above
> mentioned Create statement:
>
> TRAP: FailedAssertion("!(!(tup->t_data->t_infomask & 0x0008))", File:
> "heapam.c", Line: 2634)
> server closed the connection unexpectedly
> Th
On Fri, Nov 10, 2017 at 9:48 AM, Amit Kapila wrote:
> On Fri, Nov 10, 2017 at 8:36 AM, Robert Haas wrote:
>> On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote:
>>> Have you set force_parallel_mode=regress; before running the
>>> statement?
>>
>> Yes, I tried that first.
>>
>>> If so, then why yo
On Fri, Nov 10, 2017 at 8:36 AM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote:
>> Have you set force_parallel_mode=regress; before running the
>> statement?
>
> Yes, I tried that first.
>
>> If so, then why you need to tune other parallel query
>> related parameters?
>
>
On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote:
> Have you set force_parallel_mode=regress; before running the
> statement?
Yes, I tried that first.
> If so, then why you need to tune other parallel query
> related parameters?
Because I couldn't get it to break the other way, I then tried th
On Fri, Nov 10, 2017 at 12:05 AM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote:
>> This change looks suspicious to me. I think here we can't use the
>> tupDesc constructed from targetlist. One problem, I could see is that
>> the check for hasOid setting in tlist_match
On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote:
> This change looks suspicious to me. I think here we can't use the
> tupDesc constructed from targetlist. One problem, I could see is that
> the check for hasOid setting in tlist_matches_tupdesc won't give the
> correct answer. In case of th
On Wed, Nov 8, 2017 at 1:02 AM, Andres Freund wrote:
> Hi,
>
> On 2017-11-06 10:56:43 +0530, Amit Kapila wrote:
>> On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund wrote
>> > On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
>> >> skip-gather-project-v1.patch does what it says on the tin. I still
>>
Hi,
On 2017-11-06 10:56:43 +0530, Amit Kapila wrote:
> On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund wrote
> > On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
> >> skip-gather-project-v1.patch does what it says on the tin. I still
> >> don't have a test case for this, and I didn't find that it
Hi --
pgsql-hackers-ow...@postgresql.org wrote on 11/06/2017 09:47:22 AM:
> From: Andres Freund
>
> Hi,
>
> Please don't top-quote on postgresql lists.
Sorry
>
> On 2017-11-06 09:44:24 -0600, Jim Van Fleet wrote:
> > > >hammerdb, in this configuration, runs a variant of tpcc
> > >
> > > Ha
Hi,
Please don't top-quote on postgresql lists.
On 2017-11-06 09:44:24 -0600, Jim Van Fleet wrote:
> > >hammerdb, in this configuration, runs a variant of tpcc
> >
> > Hard to believe that any of the changes here are relevant in that
> > case - this is parallelism specific stuff. Whereas tpcc i
correct
> >hammerdb, in this configuration, runs a variant of tpcc
>
> Hard to believe that any of the changes here are relevant in that
> case - this is parallelism specific stuff. Whereas tpcc is oltp, right?
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevi
On November 6, 2017 7:30:49 AM PST, Jim Van Fleet wrote:
>Andres Freund wrote on 11/05/2017 03:40:15 PM:
>
>hammerdb, in this configuration, runs a variant of tpcc
Hard to believe that any of the changes here are relevant in that case - this
is parallelism specific stuff. Whereas tpcc is oltp
Andres Freund wrote on 11/05/2017 03:40:15 PM:
hammerdb, in this configuration, runs a variant of tpcc
>
> What query(s) did you measure?
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund wrote
> On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
>> skip-gather-project-v1.patch does what it says on the tin. I still
>> don't have a test case for this, and I didn't find that it helped very
>> much,
I am also wondering in which case it can
Hi,
On November 5, 2017 1:33:24 PM PST, Jim Van Fleet wrote:
>Ran this change with hammerdb on a power 8 firestone
>
>with 2 socket, 20 core
>9.6 base-- 451991 NOPM
>0926_master -- 464385 NOPM
>11_04master -- 449177 NOPM
>11_04_patch -- 431423 NOPM
>-- two socket patch is a little down
Ran this change with hammerdb on a power 8 firestone
with 2 socket, 20 core
9.6 base-- 451991 NOPM
0926_master -- 464385 NOPM
11_04master -- 449177 NOPM
11_04_patch -- 431423 NOPM
-- two socket patch is a little down from previous base runs
With one socket
9.6 base -- 393727 NO
On Sun, Nov 5, 2017 at 2:24 AM, Andres Freund wrote:
>> shm-mq-reduce-receiver-latch-set-v1.patch causes the receiver to only
>> consume input from the shared queue when the amount of unconsumed
>> input exceeds 1/4 of the queue size. This caused a large performance
>> improvement in my testing b
On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
> skip-gather-project-v1.patch does what it says on the tin. I still
> don't have a test case for this, and I didn't find that it helped very
> much, but it would probably help more in a test case with more
> columns, and you said this looked like a
On Sat, Nov 4, 2017 at 5:55 PM, Andres Freund wrote:
>> master: 21436.745, 20978.355, 19918.617
>> patch: 15896.573, 15880.652, 15967.176
>>
>> Median-to-median, that's about a 24% improvement.
>
> Neat!
With the attached stack of 4 patches, I get: 10811.768 ms, 10743.424
ms, 10632.006 ms, about
Hi,
On 2017-11-04 16:38:31 +0530, Robert Haas wrote:
> On hydra (PPC), these changes didn't help much. Timings:
>
> master: 29605.582, 29753.417, 30160.485
> patch: 28218.396, 27986.951, 26465.584
>
> That's about a 5-6% improvement. On my MacBook, though, the
> improvement was quite a bit more:
On Wed, Oct 18, 2017 at 3:09 AM, Andres Freund wrote:
> 2) The spinlocks both on the the sending and receiving side a quite hot:
>
>rafia query leader:
> + 36.16% postgres postgres[.] shm_mq_receive
> + 19.49% postgres postgres[.] s_lock
> + 13.24% postgres
On Thu, Oct 19, 2017 at 1:16 AM, Robert Haas wrote:
> On Tue, Oct 17, 2017 at 5:39 PM, Andres Freund wrote:
>
>>b) Use shm_mq_sendv in tqueue.c by batching up insertions into the
>> queue whenever it's not empty when a tuple is ready.
>
> Batching them with what? I hate to postpone sen
On Wed, Oct 18, 2017 at 3:09 AM, Andres Freund wrote:
> Hi Everyone,
>
> On 2017-05-19 17:25:38 +0530, Rafia Sabih wrote:
>> While analysing the performance of TPC-H queries for the newly developed
>> parallel-operators, viz, parallel index, bitmap heap scan, etc. we noticed
>> that the time taken
On Wed, Oct 18, 2017 at 4:30 PM, Andres Freund wrote:
> Hm. I'm a bit confused/surprised by that. What'd be the worst that can
> happen if we don't immediately detect that the other side is detached?
> At least if we only do so in the non-blocking paths, the worst that
> seems that could happen is
Hi,
On 2017-10-18 15:46:39 -0400, Robert Haas wrote:
> > 2) The spinlocks both on the the sending and receiving side a quite hot:
> >
> >rafia query leader:
> > + 36.16% postgres postgres[.] shm_mq_receive
> > + 19.49% postgres postgres[.] s_lock
> > + 13.24%
On Tue, Oct 17, 2017 at 5:39 PM, Andres Freund wrote:
> The precise query doesn't really matter, the observations here are more
> general, I hope.
>
> 1) nodeGather.c re-projects every row from workers. As far as I can tell
>that's now always exactly the same targetlist as it's coming from the
Hi,
On 2017-10-17 14:39:57 -0700, Andres Freund wrote:
> I've spent some time looking into this, and I'm not quite convinced this
> is the right approach. Let me start by describing where I see the
> current performance problems around gather stemming from.
One further approach to several of the
Hi Everyone,
On 2017-05-19 17:25:38 +0530, Rafia Sabih wrote:
> While analysing the performance of TPC-H queries for the newly developed
> parallel-operators, viz, parallel index, bitmap heap scan, etc. we noticed
> that the time taken by gather node is significant. On investigation, as per
> the
On Tue, Oct 17, 2017 at 3:22 AM, Andres Freund wrote:
> Hi Rafia,
>
> On 2017-05-19 17:25:38 +0530, Rafia Sabih wrote:
>> head:
>> explain analyse select * from t where i < 3000;
>> QUERY PLAN
>
> Could you share how exactly you generat
Hi Rafia,
On 2017-05-19 17:25:38 +0530, Rafia Sabih wrote:
> head:
> explain analyse select * from t where i < 3000;
> QUERY PLAN
Could you share how exactly you generated the data? Just so others can
compare a bit better with your res
Thanks Rafia, Amit, now I understand the ideas behind the patch better.
I'll see if I can look at the new one.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Sat, Sep 9, 2017 at 8:14 AM, Amit Kapila wrote:
> On Fri, Sep 8, 2017 at 11:07 PM, Alexander Kuzmenkov
> wrote:
>> Hi Rafia,
>>
>> I like the idea of reducing locking overhead by sending tuples in bulk. The
>> implementation could probably be simpler: you could extend the API of shm_mq
>> to d
On Fri, Sep 8, 2017 at 11:07 PM, Alexander Kuzmenkov
wrote:
> Hi Rafia,
>
> I like the idea of reducing locking overhead by sending tuples in bulk. The
> implementation could probably be simpler: you could extend the API of shm_mq
> to decouple notifying the sender from actually putting data into
Hi Rafia,
I like the idea of reducing locking overhead by sending tuples in bulk.
The implementation could probably be simpler: you could extend the API
of shm_mq to decouple notifying the sender from actually putting data
into the queue (i.e., make shm_mq_notify_receiver public and make a
va
On Fri, May 19, 2017 at 5:58 PM, Robert Haas wrote:
> On Fri, May 19, 2017 at 7:55 AM, Rafia Sabih
> wrote:
>> While analysing the performance of TPC-H queries for the newly developed
>> parallel-operators, viz, parallel index, bitmap heap scan, etc. we noticed
>> that the time taken by gather no
On Fri, May 19, 2017 at 7:55 AM, Rafia Sabih
wrote:
> While analysing the performance of TPC-H queries for the newly developed
> parallel-operators, viz, parallel index, bitmap heap scan, etc. we noticed
> that the time taken by gather node is significant. On investigation, as per
> the current me
36 matches
Mail list logo
