Re: drop/truncate table sucks for large values of shared buffers - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: drop/truncate table sucks for large values of shared buffers
Date
Msg-id CAA4eK1+xm1=if3UnbVe05NP5n2LfVFvKZRUoABfJXvzSFAYwQA@mail.gmail.com
Whole thread Raw
In response to Re: drop/truncate table sucks for large values of shared buffers  (Gurjeet Singh <gurjeet@singh.im>)
List 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 by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: pg_file_settings view vs. Windows
Next
From: Amit Kapila
Date:
Subject: Re: Semantics of pg_file_settings view