Re: pgsql: Add Result Cache executor node

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: David Rowley <drowley(at)postgresql(dot)org>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add Result Cache executor node
Date: 2021-04-01 00:23:41
Message-ID: CAApHDvq_hydhfovm4=izgWs+C5HqEeRScjMbOgbpC-jRAeK3Yw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Thu, 1 Apr 2021 at 12:32, David Rowley <drowley(at)postgresql(dot)org> wrote:
> Add Result Cache executor node

I'm not really sure why yet why many buildfarm members don't like this.

You can see below that the Index scan was executed 20 times (loops=20)

-> Result Cache (actual rows=1 loops=1000)
Cache Key: t2.twenty
+ Hits: 0 Misses: 0 Evictions: Zero Overflows: 0
Memory Usage: NkB
Hits: 980 Misses: 20 Evictions: Zero Overflows: 0
Memory Usage: NkB
-> Index Only Scan using tenk1_unique1 on tenk1 t1
(actual rows=1 loops=20)

So the cache surely must have been hit all but 20 times. The Index
Only Scan would only be executed during a cache miss.

It looks like it's just the stats that are being lost somewhere. I'm
really not sure why yet, so do stop the buildfarm from turning
completely red, I'll just revert this for now.

Unfortunately, that'll not help give me any ideas of why the stats are
getting lost. They're just variable in the ResultCacheState. I don't
see any reason that the code that increments these during a hit or
miss could be missed and I don't see how the stats could get zeroed
between execution and EXPLAIN either.

I'll revert and take a bit of time to look at that a bit more closely.

David

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message David Rowley 2021-04-01 00:33:43 pgsql: Revert b6002a796
Previous Message David Rowley 2021-03-31 23:55:04 Re: pgsql: Add Result Cache executor node