Re: FSM patch - performance test - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FSM patch - performance test
Date
Msg-id 23843.1221762392@sss.pgh.pa.us
Whole thread Raw
In response to Re: FSM patch - performance test  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> One thing that jumped out at me is that you call FreeSpaceMapExtendRel
>> every time a rel is extended by even one block.

> Yes, most of those calls end up being no-op. Which is exactly why I 
> would be surprised if those made any difference. It does call 
> smgrnblocks(), though, which isn't completely free...

No, it's a kernel call (at least one) which makes it pretty expensive.

I wonder whether it's necessary to do FreeSpaceMapExtendRel at this
point at all?  Why not lazily extend the map when you are told to store
a nonzero space category for a page that's off the end of the map?
Whether or not this saved many cycles overall, it'd push most of the map
extension work to VACUUM instead of having it happen in foreground.

A further refinement would be to extend the map only for a space
category "significantly" greater than zero --- maybe a quarter page or
so.  For an insert-only table that would probably result in the map
never growing at all, which might be nice.  However it would go back to
the concept of FSM being lossy; I forget whether you were hoping to get
away from that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joshua Drake
Date:
Subject: Re: Where to Host Project
Next
From: Tom Lane
Date:
Subject: Re: New FSM patch