Re: [HACKERS] Declarative partitioning - another take

Поиск
Список
Период
Сортировка
От Ildar Musin
Тема Re: [HACKERS] Declarative partitioning - another take
Дата
Msg-id fc4afab5-a545-9884-8d59-55c3fece4791@postgrespro.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] Declarative partitioning - another take  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

On 13.12.2016 21:10, Robert Haas wrote:
> On Tue, Dec 13, 2016 at 12:22 PM, Ildar Musin <i.musin@postgrespro.ru> wrote:
>> We've noticed that PartitionDispatch object is built on every INSERT query
>> and that it could create unnecessary overhead. Wouldn't it be better to keep
>> it in relcache?
>
> You might be able to cache some of that data in the relcache, but List
> *keystate is pointing to query-lifespan data, so you can't cache that.
>

Yes, you are right. I meant mostly the 'indexes' field. I've measured 
insert performance with perf in case when there are thousand partitions 
and it seems that 34% of the time it takes to run 
RelationGetPartitionDispatchInfo() which builds this indexes array. And 
the most of the time it spends on acquiring locks on all partitions 
which is unnecessary if we're inserting in just a single partition. 
Probably we could avoid this by moving at least indexes field into cache.

-- 
Ildar Musin
i.musin@postgrespro.ru



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: pg_authid.rolpassword format (was Re: [HACKERS] Passwordidentifiers, protocol aging and SCRAM protocol)
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: [HACKERS] pg_catversion builtin function