Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Moser <peter(dot)moser(at)unibz(dot)it>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PROPOSAL] Temporal query processing with range types
Date: 2017-11-16 15:42:35
Message-ID: CA+TgmoZ=UkRzpisqK5Qox_ekLG+SQP=xBeFiDkXTgLF_=1FH+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 16, 2017 at 3:32 AM, Peter Moser <peter(dot)moser(at)unibz(dot)it> wrote:
> Thank you for your feedback. We'll have a look at this and come back to you.

Another thing to think about is that even though the CURRENT
implementation just rewrites the relevant constructs as SQL, in the
future somebody might want to do something else. I feel like it's not
hard to imagine a purpose-build ALIGN or NORMALIZE join type being a
lot faster than the version that's just done by rewriting the SQL.
That would be more work, potentially, but it would be nice if the
initial implementation leant itself to be extended that way in the
future, which an all-rewriter implementation would not. On the other
hand, maybe an early-in-the-optimizer implementation wouldn't either,
and maybe it's not worth worrying about it anyway. But it would be
cool if this worked out in a way that meant it could be further
improved without having to change it completely.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Clift 2017-11-16 15:51:41 Re: Schedule for migration to pglister
Previous Message Aaron W. Swenson 2017-11-16 15:40:27 Re: pspg - psql pager