RE: Unnecessary locks for partitioned tables

Поиск
Список
Период
Сортировка
От
Тема RE: Unnecessary locks for partitioned tables
Дата
Msg-id 01bc01d8f44d$7b7f0250$727d06f0$@aeronavigator.ru
обсуждение исходный текст
Ответ на Re: Unnecessary locks for partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Unnecessary locks for partitioned tables  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-general
> <n.kobzarev@aeronavigator.ru> writes:
> > Oh, I did not explicitly write that, in case of custom plan (first
attempts or with force_custom_plan) database 
> > holds only a couple of locks! 
> > Why in this > case it is sufficient to lock only one partition and
parent table ?

> Because partition routing is done at planning time in that case, based on
the actual values of the plan's  parameters.  
> A generic plan doesn't have the parameter values available, so it has to
build plan nodes for every partition that could conceivably be accessed.
> So for queries of this kind (ie point queries against heavily partitioned
> tables) the generic plan is pretty much always going to lose.  
> That doesn't bother me enormously --- there are other query patterns with
similar behavior.

> If you know that your queries always need custom plans, I question the
value of using PREPARE at all.
>
>            regards, tom lane


Thank you for your time, Tom.
PREPARE is not mandatory, it is mostly for reproducing purposes. Queries in
stored procedures behaves like prepared statements too, that is expected. 
If someone would create delayed locking for generic plans, after parameters
are known and partition pruning occurs, I believe generic plan will be on
pars with custom.
So, I`m sticking with plan cache parameter for feature development, that was
clear.


Thanks,
Nikolay





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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Unnecessary locks for partitioned tables
Следующее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: copy file from a client app to remote postgres isntance