| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] path toward faster partition pruning |
| Date: | 2018-04-07 03:42:21 |
| Message-ID: | CAKJS1f9cAEGAhh1BTw4oM2k4qmrT+Y7jJj6vgeArxGYuF1cOpw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7 April 2018 at 15:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm also wondering how come we had hash partitioning before and
> did not have this sort of problem. Is it just that we added a
> new test that's more sensitive to the details of the hashing
> (if so, could it be made less so)? Or is there actually more
> platform dependence now than before (and if so, why is that)?
We didn't prune HASH partitions before today. They were just all returned.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-04-07 03:46:22 | Re: [HACKERS] path toward faster partition pruning |
| Previous Message | Tom Lane | 2018-04-07 03:41:22 | Re: [HACKERS] path toward faster partition pruning |