From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Partition prune with stable Expr |
Date: | 2020-09-28 01:15:31 |
Message-ID: | 194455.1601255731@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> writes:
> Well, that's very interesting. Specific to my user case,
> SELECT * FROM p WHERE pkey = to_date('2018-12-13', 'yyyy-mm-dd)';
> p has 1500+ partitions and planning takes lots of time, which is so same
> with SELECT * FROM p WHERE pkey = '2018-12-13', however the planning
> time difference is so huge, that doesn't make sense in human view. Can
> we do something for that? to_date(text, text) should be a "immutable"
> function IMO. Does that have a semantic issue or other issues?
Yeah. It depends on the lc_time setting, and possibly also the timezone
GUC. (Admittedly, common values of the format string would not have
any lc_time dependency, but the immutability property is not fine-grained
enough to recognize that.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-09-28 01:19:40 | Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration |
Previous Message | Tom Lane | 2020-09-28 01:04:06 | Re: calling procedures is slow and consumes extra much memory against calling function |