Re: Using each rel as both outer and inner for JOIN_ANTI

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Using each rel as both outer and inner for JOIN_ANTI
Дата
Msg-id 2169798.1680729071@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Using each rel as both outer and inner for JOIN_ANTI  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Using each rel as both outer and inner for JOIN_ANTI  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> Thanks for reminding.  Attached is the rebased patch, with no other
> changes.  I think the patch is ready for commit.

Pushed after a little further fooling with the comments.  I also had
to rebase it over 11c2d6fdf (Parallel Hash Full Join).  I think I did
that correctly, but it's not clear to me whether any of the existing
test cases are now doing parallelized hashed right antijoins.  Might
be worth a little more testing.

I think that Alvaro's concern about incorrect cost estimates may be
misplaced.  I couldn't find any obvious errors in the costing logic for
this, given that we concluded that the early-exit runtime logic cannot
apply.  Also, when I try simply executing Richard's original test query
(in a non-JIT build), the runtimes I get line up quite well ... maybe
too well? ... with the cost estimates:

            v15        HEAD w/patch    Ratio

Cost estimate        173691.19    90875.33    0.52
Actual (best of 3)    514.200 ms    268.978 ms    0.52

I think the smaller differentials you guys were seeing were all about
EXPLAIN ANALYZE overhead.

            regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Should vacuum process config file reload more often
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode