Re: postgres_fdw batching vs. (re)creating the tuple slots

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: postgres_fdw batching vs. (re)creating the tuple slots
Дата
Msg-id 20210530212616.5k5nxnbunwnwet2a@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: postgres_fdw batching vs. (re)creating the tuple slots  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: postgres_fdw batching vs. (re)creating the tuple slots  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2021-05-30 17:10:59 -0400, Tom Lane wrote:
> But it does seem like the hashing scheme somebody added to resowners
> is a bit too simplistic.  It ought to be able to cope with lots of
> refs to the same object, or at least not be extra-awful for that case.

It's not really the hashing that's the problem, right? The array
representation would have nearly the same problem, I think?

It doesn't seem trivial to improve it without making resowner.c's
representation a good bit more complicated. Right now there's no space
to store a 'per resowner & tupdesc refcount'. We can't even just make
the tuple desc reference a separate allocation (of (tupdesc, refcount)),
because ResourceArrayRemove() relies on testing for equality with ==.

I think we'd basically need an additional version of ResourceArray (type
+ functions) which can store some additional data for each entry?

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw batching vs. (re)creating the tuple slots
Следующее
От: Andres Freund
Дата:
Сообщение: Re: storing an explicit nonce