Luke Lonergan wrote:
> Why not contribute something - put up proof of your stated 8KB versus
> 32KB page size improvement.
I did observe that 32KB block sizes were a significant win "for our
usage patterns". It might be a win for any of the following reasons:
0) The preliminaries: ~300GB database with about ~50GB daily
turnover. Our data is fairly reasonably grouped. If we're getting one
item on a page we're usually looking at the other items as well.
1) we can live with a smaller FSM size. We were often leaking pages
with a 10M page FSM setting. With 32K pages, a 10M FSM size is
sufficient. Yes, the solution to this is "run vacuum more often", but
when the vacuum was taking 10 hours at a time, that was hard to do.
2) The typical datum size in our largest table is about 2.8KB, which is
more than 1/4 page size thus resulting in the use of a toast table.
Switching to 32KB pages allows us to get a decent storage of this data
into the main tables, thus avoiding another table and associated large
index. Not having the extra index in memory for a table with 90M rows
is probably beneficial.
3) vacuum time has been substantially reduced. Vacuum analyze now run
in the 2 to 3 hour range depending on load.
4) less cpu time spent in the kernel. We're basically doing 1/4 as many
system calls.
Overall the system has now been working well. We used to see the
database being a bottleneck at times, but now it's keeping up nicely.
Hope this helps.
Happy Thanksgiving!
-- Alan