Re: [HACKERS] Optimise default partition scanning while adding new partition - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Optimise default partition scanning while adding new partition
Date
Msg-id CA+Tgmoa_8Kjbjz4gYM1TTVv3j8RW5pSRJnHxK4Q-V8hnMRcpKw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Optimise default partition scanning while adding newpartition  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] Optimise default partition scanning while adding new partition
List pgsql-hackers
On Fri, Sep 15, 2017 at 2:00 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> I wonder if we should call check_default_allows_bound() from
> ATExecAttachPartition(), too, instead of validating updated default
> partition constraint using ValidatePartitionConstraints()?  That is, call
> the latter only to validate the partition constraint of the table being
> attached and call check_default_allows_bound() to validate the updated
> default partition constraint.  That way, INFO/ERROR messages related to
> default partition constraint are consistent across the board.

I believe the intended advantage of the current system is that if you
specify multiple operations in a single ALTER TABLE command, you only
do one scan rather than having a second scan per operation.  If that's
currently working, we probably don't want to make it stop working.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Re: [bug fix] PG10: libpq doesn't connect toalternative hosts when some errors occur