| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add support for AT LOCAL |
| Date: | 2023-06-25 00:14:52 |
| Message-ID: | b3eb8019-c2db-557a-355b-7b02d6bc1cfb@postgresfriends.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/12/23 17:37, Alvaro Herrera wrote:
> On 2023-Jun-06, Laurenz Albe wrote:
>
>> At a quick glance, it looks like you resolve "timezone" at the time
>> the query is parsed. Shouldn't the resolution happen at query
>> execution time?
>
> Sounds like it -- consider the case where the timestamp value is a
> partition key and one of the partition boundaries falls in between two
> timezone offsets for some particular ts value; then you use a prepared
> query to read from a view defined with AT LOCAL. Partition pruning
> would need to compute partitions to read from at runtime, not plan time.
Can you show me an example of that happening with my patch?
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Coleman | 2023-06-25 02:24:37 | Re: Stampede of the JIT compilers |
| Previous Message | David Rowley | 2023-06-25 00:14:34 | Re: Stampede of the JIT compilers |