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
|
Список | 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 по дате отправления: