| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| 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:41:22 |
| Message-ID: | 4417.1523072482@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> Sounds like you're saying that if we have too many alternative files
> then there's a chance that one could pass by luck.
Yeah, exactly: it passed, but did it pass for the right reason?
If there's just two expected-files, it's likely not a big problem,
but if you have a bunch it's something to worry about.
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)?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-04-07 03:42:21 | Re: [HACKERS] path toward faster partition pruning |
| Previous Message | Ashutosh Bapat | 2018-04-07 03:39:23 | Re: [HACKERS] path toward faster partition pruning |