Re: making update/delete of inheritance trees scale better - Mailing list pgsql-hackers

From Tom Lane
Subject Re: making update/delete of inheritance trees scale better
Date
Msg-id 3230221.1617211441@sss.pgh.pa.us
Whole thread Raw
In response to Re: making update/delete of inheritance trees scale better  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making update/delete of inheritance trees scale better  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 30, 2021 at 12:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Maybe that could be made more robust, but the other problem
>> is that the EXPLAIN output is just about unreadable; nobody will
>> understand what "(0)" means.

> I think this was an idea that originally came from me, prompted by
> what we already do for:

I agree that we have some existing behavior that's related to this, but
it's still messy, and I couldn't find any evidence that suggested that the
runtime lookup costs anything.  Typical subplans are going to deliver
long runs of tuples from the same target relation, so as long as we
maintain a one-element cache of the last lookup result, it's only about
one comparison per tuple most of the time.

> I think the real
> problem here is that the deparsing code isn't in on the secret.

Agreed; if we spent some more effort on that end of it, maybe we
could do something different here.  I'm not very sure what good
output would look like though.  A key advantage of tableoid is
that that's already a thing people know about.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Next
From: Jaime Casanova
Date:
Subject: Crash in BRIN minmax-multi indexes