Re: pgsql: Add Result Cache executor node

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: pgsql: Add Result Cache executor node
Дата
Msg-id be36e038-9b68-ad57-d70e-d1d7369fde91@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pgsql: Add Result Cache executor node  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: Add Result Cache executor node  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: pgsql: Move some client-specific routines from SSLServer to PostgresNod
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Add Result Cache executor node