Re: ResultCache cache error: "cache entry already complete" in 14beta1

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: David Christensen <david(dot)christensen(at)crunchydata(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, David Rowley <drowley(at)postgresql(dot)org>
Subject: Re: ResultCache cache error: "cache entry already complete" in 14beta1
Date: 2021-05-22 04:31:29
Message-ID: CAApHDvrkXT+zhrusz7xdRBS3jZR=kB32AgBc4cnFCtxTaxQHvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, 22 May 2021 at 02:00, David Christensen
<david(dot)christensen(at)crunchydata(dot)com> wrote:
> I can confirm that this fixes the issue in our case (both in the actual query and in the minimal reproduction case).

Thank you for checking that.

I looked at the patch again and realised that if we don't make the
result cache singlerow == true with a unique join that since Nested
Loop just skips to the next outer tuple after it matches to an inner
tuple, that the only chance we'll get to mark a cache entry as
complete will be for outer tuples that have no matching inner tuple.
That's the only time we'll run the inner scan to completion with
unique joins. That would mean that we'd never get any cache hits for
sets of parameters that do have some matching inner rows. Remember a
cache hit is can only use the cache entry if the entry is marked as
complete. Otherwise, there might be missing tuples. Such a scenario
might be common with ANTI joins, but since we don't currently detect
unique joins for those, that's a case we'll never hit.

I ended up pushing a patch that just does not consider a Result Cache
path for unique joins where the parameterisation is not the entire
join condition. That'll mean the plan will change in your test case
when beta2 comes out.

David

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2021-05-22 05:39:46 Re: BUG #17005: Enhancement request: Improve walsender throughput by aggregating multiple messages in one send
Previous Message Yuri Astrakhan 2021-05-21 21:54:16 Re: BUG #16076: JIT causes huge delays in a complex query. jit=off solves it.