From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [POC] Faster processing at Gather node |
Date: | 2017-10-18 05:33:41 |
Message-ID: | 20171018053341.53f5kfxeq7sqytjc@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 these issues could also be to change
things a bit more radically:
Instead of the current shm_mq + tqueue.c, have a drastically simpler
queue, that just stores fixed width dsa_pointers. Dealing with that
queue will be quite a bit faster. In that queue one would store dsa.c
managed pointers to tuples.
One thing that makes that attractive is that that'd move a bunch of
copying in the leader process solely to the worker processes, because
the leader could just convert the dsa_pointer into a local pointer and
hand that upwards the execution tree.
We'd possibly need some halfway clever way to reuse dsa allocations, but
that doesn't seem impossible.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-10-18 07:16:55 | Re: pgbench: Skipping the creating primary keys after initialization |
Previous Message | Dilip Kumar | 2017-10-18 04:23:10 | Re: Partition-wise aggregation/grouping |