Re: [HACKERS] [POC] Faster processing at Gather node

From: "Tels" <nospam-pg-abuse(at)bloodgate(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Andres Freund" <andres(at)anarazel(dot)de>, "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Rafia Sabih" <rafia(dot)sabih(at)enterprisedb(dot)com>, "PostgreSQL Developers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [POC] Faster processing at Gather node
Date: 2018-03-02 22:21:28
Message-ID: e66e05bc55f5ce904e361ad17a3395ae.squirrel@sm.webmail.pair.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Robert,

On Fri, March 2, 2018 12:22 pm, Robert Haas wrote:
> On Wed, Feb 28, 2018 at 10:06 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
>> [ latest patches ]
>
> Committed. Thanks for the review.

Cool :)

There is a typo, tho:

+ /*
+ * If the counterpary is known to have attached, we can read mq_receiver
+ * without acquiring the spinlock and assume it isn't NULL. Otherwise,
+ * more caution is needed.
+ */

s/counterpary/counterparty/;

Sorry, only noticed while re-reading the thread.

Also, either a double space is missing, or one is too many:

+ /*
+ * Separate prior reads of mq_ring from the increment of mq_bytes_read
+ * which follows. Pairs with the full barrier in shm_mq_send_bytes(). We
+ * only need a read barrier here because the increment of mq_bytes_read is
+ * actually a read followed by a dependent write.
+ */

(" Pairs ..." vs. ". We only ...")

Best regards,

Tels

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2018-03-02 22:32:58 Re: [PATCH] Opclass parameters
Previous Message Tom Lane 2018-03-02 22:17:29 Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.