Re: [HACKERS] Partitioning vs ON CONFLICT - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] Partitioning vs ON CONFLICT
Date
Msg-id CAH2-Wz=0KgENk9LUGtY-9mgmQHDYj-4W3JePf8J+KK_2PtsPCA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Partitioning vs ON CONFLICT  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] Partitioning vs ON CONFLICT
List pgsql-hackers
On Thu, Feb 16, 2017 at 8:21 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> would be working on a leaf partition chosen by tuple-routing after an
> insert on a partitioned table.  The leaf partitions can very well have a
> unique index, which can be used for inference.  The problem however is
> that infer_arbiter_indexes() in the optimizer would be looking at the root
> partitioned, which cannot yet have any indexes defined on them, let alone
> unique indexes.  When we develop a feature where defining an index on the
> root partitioned table would create the same index on all the leaf
> partitions and then extend it to support unique indexes, then we can
> perhaps talk about supporting ON CONFLICT handing.  Does that make sense?

Yes, that makes sense, but I wasn't arguing that that should be
possible today. I was arguing that when you don't spell out an
arbiter, which ON CONFLICT DO NOTHING permits, then it should be
possible for it to just work today -- infer_arbiter_indexes() will
return immediately.

This should be just like the old approach involving inheritance, in
that that should be possible. No?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Partitioning vs ON CONFLICT
Next
From: Rafia Sabih
Date:
Subject: Re: [HACKERS] Parallel Index-only scan