Re: Joins on TID

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Joins on TID
Дата
Msg-id CANP8+jJ2ggwyA8AhHUw8e8dzw9AN-ntYN9o0wT63vkRQHh2rRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Joins on TID  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, 22 Dec 2018 at 16:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
 
What I'm thinking about in this thread is joins on TID, which we have only
very weak support for today --- you'll basically always wind up with a
mergejoin, which requires full-table scan and sort of its inputs.  Still,
that's better than a naive nestloop, and for years we've been figuring
that that was good enough.  Several people in the other thread that
I cited felt that that isn't good enough.  But if we think it's worth
taking seriously, then IMO we need to add both parameterized scans (for
nestloop-with-inner-fetch-by-tid) and hash join, because each of those
can dominate depending on how many tuples you're joining.

That would certainly help if you are building a column store, or other new index types. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Speeding up text_position_next with multibyte encodings