From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: making update/delete of inheritance trees scale better |
Date: | 2021-03-31 17:24:01 |
Message-ID: | 3230221.1617211441@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 30, 2021 at 12:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2021-03-31 17:29:33 | Crash in BRIN minmax-multi indexes |
Previous Message | Julien Rouhaud | 2021-03-31 17:16:44 | Re: Idea: Avoid JOINs by using path expressions to follow FKs |