Re: pgsql: Add Result Cache executor node

On Thu, 1 Apr 2021 at 14:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

Yeah, florican is not failing in the same way. It does look like I'll
need to blank out the heap blocks too. I missed that.

I suspect you're right about the 32-bit thing. The cache will use less
memory for pointers on that machine and the test, which I purposefully
kept small so it was not too slow might just not fill the cache enough
to cause any evictions due to that.

- Hits: Zero Misses: N Evictions: N Overflows: 0
Memory Usage: NkB
+ Hits: Zero Misses: N Evictions: Zero Overflows: 0
Memory Usage: NkB
-> Index Only Scan using tenk1_unique1 on tenk1 t1
(actual rows=1 loops=800)

I might just need to scale that test up a bit. I'm already using 64kb
of work_mem, the lowest possible setting.

It looks like there are no issues recording the cache misses on that
machine given that the censored value says "N" rather than "Zero".

David