Re: ON CONFLICT DO UPDATE for partitioned tables - Mailing list pgsql-hackers

From Amit Langote
Subject Re: ON CONFLICT DO UPDATE for partitioned tables
Date
Msg-id 0fa64646-b9a4-85ba-8847-d3acdbd89d0e@lab.ntt.co.jp
Whole thread Raw
In response to Re: ON CONFLICT DO UPDATE for partitioned tables  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: ON CONFLICT DO UPDATE for partitioned tables  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 2018/04/18 22:40, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2018/04/18 0:04, Alvaro Herrera wrote:
>>> Amit Langote wrote:
>>>
>>>> I just confirmed my hunch that this wouldn't somehow do the right thing
>>>> when the OID system column is involved.  Like this case:
>>>
>>> This looks too big a patch to pursue now.  I'm inclined to just remove
>>> the equalTupdesc changes.
>>
>> OK.  Here is the patch that removes equalTupdesc optimization.
> 
> Hmm.  If we modify (during pg12, of course -- not now) partition tables
> that are created identical to their parent table so that they share the
> pg_type row, this would become useful.  Unless there a reason why that
> change is completely unworkable, I'd just leave it there.  (I claim that
> it works like that only because it used to work like that, not because
> it's impossible to make work the other way.)

Yeah, I too have wondered in the past what it would take to make
equalTupDescs() return true for parent and partitions.  Maybe we can make
it work by looking a bit harder than I did then.

Although, just leaving it there now would mean we're adding a few cycles
needlessly in the PG 11 code.  Why not add that optimization when we
surely know it can work?

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Problem while setting the fpw with SIGHUP
Next
From: Michael Paquier
Date:
Subject: Re: Adding an LWLockHeldByMe()-like function that reports if anybuffer content lock is held