| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, David Rowley <drowley(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Add Result Cache executor node |
| Date: | 2021-04-01 01:36:23 |
| Message-ID: | 3349222.1617240983@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 4/1/21 2:52 AM, Tom Lane wrote:
>> 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.
That might well explain some of it, but not all those unhappy machines
are using force_parallel_mode --- florican isn't, for one. Now that
I look at it, I'd bet florican's diffs [1] are a 32-bit vs 64-bit issue
and not directly related to what David wants to test at all.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican&dt=2021-04-01%2000%3A28%3A12
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2021-04-01 01:43:04 | Re: pgsql: Extended statistics on expressions |
| Previous Message | Tomas Vondra | 2021-04-01 01:15:38 | Re: pgsql: Add Result Cache executor node |