From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Another way to fix inherited UPDATE/DELETE |
Date: | 2019-02-21 03:50:44 |
Message-ID: | 5C6E2014.10406@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2019/02/21 0:14), Tom Lane wrote:
> Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> (2019/02/20 6:48), Tom Lane wrote:
>>> In the case of a standard inheritance or partition tree, this seems to
>>> go through really easily, since all the children could share the same
>>> returned CTID column (I guess you'd also need a TABLEOID column so you
>>> could figure out which table to direct the update back into). It gets
>>> a bit harder if the tree contains some foreign tables, because they might
>>> have different concepts of row identity, but I'd think in most cases you
>>> could still combine those into a small number of output columns.
>
>> If this is the direction we go in, we should work on the row ID issue
>> [1] before this?
>
> Certainly, the more foreign tables can use a standardized concept of row
> identity, the better this would work. What I'm loosely envisioning is
> that we have one junk row-identity column for each distinct row-identity
> datatype needed --- so, for instance, all ordinary tables could share
> a TID column. Different FDWs might need different things, though one
> would hope for no more than one datatype per FDW-type involved in the
> inheritance tree. Where things could break down is if we have a lot
> of tables that need a whole-row-variable for row identity, and they're
> all different rowtypes --- eventually we'd run out of available columns.
> So we'd definitely wish to encourage FDWs to have some more efficient
> row-identity scheme than that one.
Seems reasonable. I guess that that can address not only the issue [1]
but our restriction on FDW row locking that APIs for that currently only
allow TID for row identity, in a uniform way.
> I don't see that as being something that constrains those two projects
> to be done in a particular order; it'd just be a nice-to-have improvement.
OK, thanks for the explanation!
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2019-02-21 03:55:31 | Re: WIP: Avoid creation of the free space map for small tables |
Previous Message | Thomas Munro | 2019-02-21 03:28:32 | Re: Refactoring the checkpointer's fsync request queue |