Re: pgsql: Add Result Cache executor node - Mailing list pgsql-committers

From Tomas Vondra
Subject Re: pgsql: Add Result Cache executor node
Date
Msg-id be36e038-9b68-ad57-d70e-d1d7369fde91@enterprisedb.com
Whole thread Raw
In response to Re: pgsql: Add Result Cache executor node  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Add Result Cache executor node  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers

On 4/1/21 2:52 AM, Tom Lane wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
>> On Thu, 1 Apr 2021 at 12:32, David Rowley <drowley@postgresql.org> wrote:
>>> Add Result Cache executor node
> 
>> I'm not really sure why yet why many buildfarm members don't like this.
> 
> Something that struck me is that the animals that stayed green were
> almost exclusively Debian and macOS, while the unhappy ones were
> uniformly not.  That pattern makes no sense --- why would Debian
> act differently from other Linuxen? --- but it sure seems real.
> 
> [ looks a bit more... ]  Actually, most of those Debian machines
> are Andres' test menagerie.  So maybe there's some commonality
> of configuration of his animals that is connected to this.
> 
> Anyway, it looks like I can probably reproduce it on florican's
> host, if you still need help understanding it tomorrow.  But
> I remain really dubious that this can work at all.  Question:
> have you tried that test under CLOBBER_CACHE_ALWAYS?
> 

I'd bet the failures are due to force_parallel_mode=regress. Notice that
it's actually *adding* one extra row with the stats, which could be
explained by stats from leader + worker. Not sure why some of the
numbers were not replaced by N, though.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-committers by date:

Previous
From: Michael Paquier
Date:
Subject: pgsql: Move some client-specific routines from SSLServer to PostgresNod
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Add Result Cache executor node