| 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 08:18:35 |
| Message-ID: | CANP8+jK2NZz9JvjcnhfyfM6bXw=+rxwLipZmPgaQUEWZJWRUug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 22 Dec 2018 at 04:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> BTW, if we're to start taking joins on TID seriously, we should also
> add the missing hash opclass for TID, so that you can do hash joins
> when dealing with a lot of rows.
>
> (In principle this also enables things like hash aggregation, though
> I'm not very clear on a use-case for grouping by TID.)
>
I don't think we are trying to do TID joins more seriously, just fix a
special case.
The case cited requires the batches of work to be small, so nested loops
works fine.
Looks to me that Edmund is trying to solve the same problem. If so, this is
the best solution.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark | 2018-12-22 09:14:05 | Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2 |
| Previous Message | Tom Lane | 2018-12-22 04:31:46 | Re: Joins on TID |