Re: pgsql: Add Result Cache executor node - Mailing list pgsql-committers

From David Rowley
Subject Re: pgsql: Add Result Cache executor node
Date
Msg-id CAApHDvq_hydhfovm4=izgWs+C5HqEeRScjMbOgbpC-jRAeK3Yw@mail.gmail.com
Whole thread Raw
In response to pgsql: Add Result Cache executor node  (David Rowley <drowley@postgresql.org>)
Responses Re: pgsql: Add Result Cache executor node  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
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.

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



pgsql-committers by date:

Previous
From: David Rowley
Date:
Subject: Re: pgsql: Add Result Cache executor node
Next
From: David Rowley
Date:
Subject: pgsql: Revert b6002a796