Re: Partition prune with stable Expr

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

In response to

Responses

Browse pgsql-hackers by date

  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