Re: SQL:2011 PERIODS vs Postgres Ranges? - Mailing list pgsql-hackers

From Paul Jungwirth
Subject Re: SQL:2011 PERIODS vs Postgres Ranges?
Date
Msg-id e80281b7-5267-6f91-aabe-0a80f24a219f@illuminatedcomputing.com
Whole thread Raw
In response to Re: SQL:2011 PERIODS vs Postgres Ranges?  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Responses Re: SQL:2011 PERIODS vs Postgres Ranges?
List pgsql-hackers
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!

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Next
From: Alexander Korotkov
Date:
Subject: Re: MultiXact\SLRU buffers configuration