Re: making update/delete of inheritance trees scale better

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: making update/delete of inheritance trees scale better
Дата
Msg-id 3230221.1617211441@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: making update/delete of inheritance trees scale better  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: making update/delete of inheritance trees scale better  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Следующее
От: Jaime Casanova
Дата:
Сообщение: Crash in BRIN minmax-multi indexes