Skip site navigation (1) Skip section navigation (2)

Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)

From: Jim Nasby <jim(at)nasby(dot)net>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Farina <daniel(at)heroku(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Date: 2012-01-21 22:29:58
Message-ID: 700ADBFE-DF86-4658-BC90-6C463B177B39@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jan 20, 2012, at 11:54 AM, Heikki Linnakangas wrote:
> On 04.01.2012 13:14, Simon Riggs wrote:
>> On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>>> Jim Nasby<jim(at)nasby(dot)net>  writes:
>>>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>>>>> This could well be related to the fact that DropRelFileNodeBuffers()
>>>>> does a scan of shared_buffers, which is an O(N) approach no matter the
>>>>> size of the index.
>>> 
>>>> Couldn't we just leave the buffers alone? Once an index is dropped and that's pushed out through the catalog then nothing should be trying to access them and they'll eventually just get aged out.
>>> 
>>> No, we can't, because if they're still dirty then the bgwriter would
>>> first try to write them to the no-longer-existing storage file.  It's
>>> important that we kill the buffers immediately during relation drop.
>>> 
>>> I'm still thinking that it might be sufficient to mark the buffers
>>> invalid and let the clock sweep find them, thereby eliminating the need
>>> for a freelist.
>> 
>> My patch puts things on the freelist only when it is free to do so.
>> Not having a freelist at all is probably a simpler way of avoiding the
>> lock contention, so I'll happily back that suggestion instead. Patch
>> attached, previous patch revoked.
> 
> So, you're proposing that we remove freelist altogether? Sounds reasonable, but that needs to be performance tested somehow. I'm not sure what exactly the test should look like, but it probably should involve an OLTP workload, and large tables being created, populated to fill the cache with pages from the table, and dropped, while the OLTP workload is running. I'd imagine that the worst case scenario looks something like that.

We should also look at having the freelist do something useful, instead of just dropping it completely. Unfortunately that's probably more work...
--
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)                         http://jim.nasby.net



In response to

Responses

pgsql-hackers by date

Next:From: Jim NasbyDate: 2012-01-21 22:54:07
Subject: Re: Vacuum rate limit in KBps
Previous:From: Peter EisentrautDate: 2012-01-21 22:13:55
Subject: Re: Review of patch renaming constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group