| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: Joins on TID | 
| Date: | 2018-12-22 19:15:02 | 
| Message-ID: | CANP8+jJ2ggwyA8AhHUw8e8dzw9AN-ntYN9o0wT63vkRQHh2rRw@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sat, 22 Dec 2018 at 16:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2018-12-23 00:26:11 | Re: Speeding up text_position_next with multibyte encodings | 
| Previous Message | Tom Lane | 2018-12-22 18:28:35 | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |