Re: SQL:2011 PERIODS vs Postgres Ranges?

From: David Steele <david(at)pgmasters(dot)net>
To: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Vik Fearing <vik(dot)fearing(at)protonmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL:2011 PERIODS vs Postgres Ranges?
Date: 2021-04-08 14:22:15
Message-ID: fcfa7d32-257f-4c6d-a22e-d134b4db2034@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/27/20 12:34 PM, Paul Jungwirth wrote:
> On 10/27/20 7:11 AM, Ibrar Ahmed wrote:
>> I have spent some more time on the patch and did a lot of
>> cleanup along with some fixes, compilation errors, and warnings.
>
> Thank you for taking a look at this! I've been swamped with ordinary
> work and haven't had a chance to focus on it for a while, but I'm hoping
> to make some improvements over the coming holidays, especially based on
> feedback from my talk at PgCon. There are a handful of small specific
> things I'd like to do, and then one big thing: add support for PERIODs.
> Vik said I could include his old patch for PERIODs, so I'd like to get
> that working on the latest master, and then rebase my own work on top of
> it. Then we can accept either ranges or PERIODs in various places
> (marked by TODOs in the code).
>
> Vik also pointed out a way to check foreign keys without using
> range_agg. He thinks it may even be more efficient. On the other hand
> it's a much more complicated SQL statement. I'd like to do a performance
> comparison to get concrete numbers, but if we did use his query, then
> this patch wouldn't depend on multiranges anymore---which seems like a
> big aid to moving it forward. Assuming multiranges gets committed, we
> can always swap in the range_agg query depending on the performance
> comparison results.
>
> I apologize for the slow progress here, and thank you for your help!

Looks like Ibrar reopened this patch in the 2020-09 CF rather than
moving it to a new one. Given that Paul has not had a chance to look at
it since then I'm setting it back to RwF.

Paul, you can submit to the next CF when you are ready with a new patch.

Regards,
--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2021-04-08 14:23:10 Re: 2019-03 CF now in progress
Previous Message Robert Haas 2021-04-08 14:13:42 Re: [PATCH] PREPARE TRANSACTION unexpected behavior with TEMP TABLE