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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tels <nospam-pg-abuse(at)bloodgate(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-29 16:18:43
Message-ID: 20180329161843.GC16165@momjian.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: 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(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,

Change applied with the attached patch.

--
Bruce Momjian <bruce(at)momjian(dot)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 Content-Type Size
shm.diff text/x-diff 1.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Catalin Iacob 2018-03-29 16:20:00 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Previous Message Alvaro Herrera 2018-03-29 16:04:06 Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.