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

On Sat, Jun 27, 2015 at 8:06 PM, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
>
> On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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