| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Alan Jackson <ajax(at)tvsquared(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: inconsistent results querying table partitioned by date |
| Date: | 2019-05-16 03:26:19 |
| Message-ID: | 6665c507-d0b0-ed1b-6c0d-25c2c8446c11@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2019/05/16 11:52, David Rowley wrote:
> I don't really see where this duplicate call is. The patch calls
> op_volatile() at the very most just once per pruning step.
Ah, there's no op_volatile() on the matched clause's operator in
match_clause_to_partition_key() when it's called during a forplanner=false
run. So, while there is a duplication of efforts because
match_clause_to_partition_key() runs twice for any given clause which is
due to original design design, there is no duplication of efforts between
match_clause_to_partition_key() and analyze_partkey_exprs().
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-05-16 03:32:38 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |
| Previous Message | Andres Freund | 2019-05-16 02:59:38 | Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND |