Re: Ordered Partitioned Table Scans - Mailing list pgsql-hackers

From David Rowley
Subject Re: Ordered Partitioned Table Scans
Date
Msg-id CAKJS1f9R2OMmctC8qz-gpvqHiMN-b28zoyT8QqW=oWx+4KfWqw@mail.gmail.com
Whole thread Raw
In response to Re: Ordered Partitioned Table Scans  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Ordered Partitioned Table Scans
List pgsql-hackers
On Tue, 2 Apr 2019 at 14:26, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> How about extending the sentence about when the optimization is disabled
> as follows:
>
> "If we find a Datum in a partition that's greater than one previously
> already seen, then values could become out of order and we'd have to
> disable the optimization.  We'd also need to disable the optimization if
> NULL values are interleaved with other Datum values, because the calling
> code expect them to be present in the last partition."
>
> Further, extend the "For now..." sentence as:
>
> "For now, let's just keep it simple and just accept LIST partitioned table
> without a DEFAULT partition where each partition only accepts a single
> Datum or NULL.  It's OK to always accept NULL partition in that case,
> because PartitionBoundInfo lists it as the last partition."

I ended up rewording the entire thing and working on the header
comment for the function too. I think previously it wasn't that well
defined what "ordered" meant. I added a mention that we expect that
NULLs, if possible must come in the last partition.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: GCoS2019--pgBackRest port to Windows (2019)
Next
From: Etsuro Fujita
Date:
Subject: Re: Problems with plan estimates in postgres_fdw