From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Elvis Pranskevichus <elprans(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize |
Date: | 2021-11-24 01:58:30 |
Message-ID: | CAApHDvpdOpUOUPPted6rFzP2ykq5Oiwg4V0ENnyNOQzZhpid_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, 22 Nov 2021 at 23:36, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Tue, 26 Oct 2021 at 20:50, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > An alternative way to fix the problem would be just to flush the cache
> > whenever a Param changes that is not part of the cache key. The
> > Materalize node works a bit like this, except it'll just flush the
> > cache whenever a param changes, since the Material cache is not
> > parameterized. One fairly hefty drawback with doing it this way is
> > that the planner does not get a chance to take into account the fact
> > that the cache could be flushed quite often. This could result in a
> > Nested Loop / Memoize join being chosen instead of a Hash or Merge
> > Join when the hash or merge join would be much more favourable. Let's
> > call this "option 2".
>
> I'm planning on giving the patch I submitted another look with the
> intention of pushing it tomorrow.
Pushed with the addition of a test to exercise the cache flushing code.
Thanks for reporting this.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-11-24 04:42:03 | Re: BUG #17288: PSQL bug with COPY command (Windows) |
Previous Message | Thomas Munro | 2021-11-23 20:23:37 | Re: BUG #17289: Postgres 14.1 Windows installer fails with unknown error and terminates |