Re: drop/truncate table sucks for large values of shared buffers

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: drop/truncate table sucks for large values of shared buffers
Дата
Msg-id CAA4eK1+xm1=if3UnbVe05NP5n2LfVFvKZRUoABfJXvzSFAYwQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: drop/truncate table sucks for large values of shared buffers  (Gurjeet Singh <gurjeet@singh.im>)
Список pgsql-hackers
On Sat, Jun 27, 2015 at 8:06 PM, Gurjeet Singh <gurjeet@singh.im> wrote:
>
> On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> Attached patch implements the above idea and I found that
>> performance doesn't dip much with patch even with large value
>> of shared_buffers.  I have also attached script and sql file used
>> to take performance data.
>
>
> +1 for the effort to improve this.
>

Thanks.

> With your technique added, there are 3 possible ways the search can happen a) Scan NBuffers and scan list of relations, b) Scan NBuffers and bsearch list of relations, and c) Scan list of relations and then invalidate blocks of each fork from shared buffers. Would it be worth it finding one technique that can serve decently from the low-end shared_buffers to the high-end.
>

Yes, it would be great if we could have any such technique, but in
absence of that current optimization would suffice the need unless
there are any loop-holes in it.

> On patch:
>
> There are multiple naming styles being used in DropForkSpecificBuffers(); my_name and myName. Given this is a new function, it'd help to be consistent.
>

Thanks for suggestions, I will improve the patch on those lines if
there is no problem with idea at broad level. 


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: pg_file_settings view vs. Windows
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Semantics of pg_file_settings view