Re: Further pg_upgrade analysis for many tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Further pg_upgrade analysis for many tables
Дата
Msg-id 24278.1352922571@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Further pg_upgrade analysis for many tables  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Further pg_upgrade analysis for many tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Further pg_upgrade analysis for many tables  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There are at least three ways we could whack that mole: ...
>>
>> * Keep a separate list (or data structure of your choice) so that
>> relcache entries created in the current xact could be found directly
>> rather than having to scan the whole relcache.  That'd add complexity
>> though, and could perhaps be a net loss for cases where the relcache
>> isn't so bloated.

> Maybe a static list that can overflow, like the ResourceOwner/Lock
> table one recently added.  The overhead of that should be very low.

> Are the three places where "need_eoxact_work = true;" the only places
> where things need to be added to the new structure?

Yeah.  The problem is not so much the number of places that do that,
as that places that flush entries from the relcache would need to know
to remove them from the separate list, else you'd have dangling
pointers.  It's certainly not impossible, I was just unsure how much
of a pain in the rear it might be.

> The next quadratic behavior is in init_sequence.

Yeah, that's another place that is using a linear list that perhaps
should be a hashtable.  OTOH, probably most sessions don't touch enough
different sequences for that to be a win.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Further pg_upgrade analysis for many tables