Re: [HACKERS] Optimise default partition scanning while adding new partition
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Optimise default partition scanning while adding new partition |
Дата | |
Msg-id | CA+Tgmoa_8Kjbjz4gYM1TTVv3j8RW5pSRJnHxK4Q-V8hnMRcpKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Optimise default partition scanning while adding newpartition (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Optimise default partition scanning while adding new partition
|
Список | 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 по дате отправления: