Re: Parallelize correlated subqueries that execute within each worker

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: Parallelize correlated subqueries that execute within each worker
Дата
Msg-id CALDaNm0vp-xLtVEwFHBjTP38ufNN1e-b6J17nDsUhNNiqZ8iHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallelize correlated subqueries that execute within each worker  (James Coleman <jtc331@gmail.com>)
Ответы Re: Parallelize correlated subqueries that execute within each worker  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
On Tue, 27 Sept 2022 at 08:26, James Coleman <jtc331@gmail.com> wrote:
>
> On Mon, Mar 21, 2022 at 8:48 PM Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> > On 2022-01-22 20:25:19 -0500, James Coleman wrote:
> > > On the other hand this is a dramatically simpler patch series.
> > > Assuming the approach is sound, it should much easier to maintain than
> > > the previous version.
> > >
> > > The final patch in the series is a set of additional checks I could
> > > imagine to try to be more explicit, but at least in the current test
> > > suite there isn't anything at all they affect.
> > >
> > > Does this look at least somewhat more like what you'd envisionsed
> > > (granting the need to squint hard given the relids checks instead of
> > > directly checking params)?
> >
> > This fails on freebsd (so likely a timing issue):
https://cirrus-ci.com/task/4758411492458496?logs=test_world#L2225
> >
> > Marked as waiting on author.
>
> I've finally gotten around to checking this out, and the issue was an
> "explain analyze" test that had actual loops different on FreeBSD.
> There doesn't seem to be a way to disable loop output, but instead of
> processing the explain output with e.g. a function (as we do some
> other places) to remove the offending and unnecessary output I've just
> removed the "analyze" (as I don't believe it was actually necessary).
>
> Attached is an updated patch series. In this version I've removed the
> "parallelize some subqueries with limit" patch since discussion is
> proceeding in the spun off thread. The first patch adds additional
> tests so that you can see how those new tests change with the code
> changes in the 2nd patch in the series. As before the final patch in
> the series includes changes where we may also want to verify
> correctness but don't have a test demonstrating the need.

The patch does not apply on top of HEAD as in [1], please post a rebased patch:

=== Applying patches on top of PostgreSQL commit ID
bf03cfd162176d543da79f9398131abc251ddbb9 ===
=== applying patch ./v5-0002-Parallelize-correlated-subqueries.patch
patching file src/backend/optimizer/path/allpaths.c
...
Hunk #5 FAILED at 3225.
Hunk #6 FAILED at 3259.
Hunk #7 succeeded at 3432 (offset -6 lines).
2 out of 7 hunks FAILED -- saving rejects to file
src/backend/optimizer/path/allpaths.c.rej

[1] - http://cfbot.cputube.org/patch_41_3246.log

Regards,
Vignesh



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Fix showing XID of a spectoken lock in an incorrect field of pg_locks view.
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Add index scan progress to pg_stat_progress_vacuum