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

From Bruce Momjian
Subject Re: [HACKERS] [POC] Faster processing at Gather node
Date
Msg-id 20180329161843.GC16165@momjian.us
Whole thread Raw
In response to Re: [HACKERS] [POC] Faster processing at Gather node  ("Tels" <nospam-pg-abuse@bloodgate.com>)
List pgsql-hackers
On Fri, Mar  2, 2018 at 05:21:28PM -0500, Tels wrote:
> 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,

Change applied with the attached patch.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
Next
From: Catalin Iacob
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS