Re: [HACKERS] [POC] Faster processing at Gather node - Mailing list pgsql-hackers

From Tels
Subject Re: [HACKERS] [POC] Faster processing at Gather node
Date
Msg-id e66e05bc55f5ce904e361ad17a3395ae.squirrel@sm.webmail.pair.com
Whole thread Raw
In response to Re: [HACKERS] [POC] Faster processing at Gather node  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [POC] Faster processing at Gather node  (Bruce Momjian <bruce@momjian.us>)
List 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@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.
Next
From: Nikita Glukhov
Date:
Subject: Re: [PATCH] Opclass parameters