diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2012-07-19 19:28:22 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2012-07-19 19:28:22 -0400 |
commit | be86e3dd5b42c33387ae976c014e6276c9439f7f (patch) | |
tree | ed8eff45341095b0b55b2a9cff9f54acf8edeba6 /src/backend/executor/functions.c | |
parent | 3072b7bade26d4cf72ad453ad7d3323927b1ea64 (diff) | |
download | postgresql-be86e3dd5b42c33387ae976c014e6276c9439f7f.tar.gz postgresql-be86e3dd5b42c33387ae976c014e6276c9439f7f.zip |
Rethink checkpointer's fsync-request table representation.
Instead of having one hash table entry per relation/fork/segment, just have
one per relation, and use bitmapsets to represent which specific segments
need to be fsync'd. This eliminates the need to scan the whole hash table
to implement FORGET_RELATION_FSYNC, which fixes the O(N^2) behavior
recently demonstrated by Jeff Janes for cases involving lots of TRUNCATE or
DROP TABLE operations during a single checkpoint cycle. Per an idea from
Robert Haas.
(FORGET_DATABASE_FSYNC still sucks, but since dropping a database is a
pretty expensive operation anyway, we'll live with that.)
In passing, improve the delayed-unlink code: remove the pass over the list
in mdpreckpt, since it wasn't doing anything for us except supporting a
useless Assert in mdpostckpt, and fix mdpostckpt so that it will absorb
fsync requests every so often when clearing a large backlog of deletion
requests.
Diffstat (limited to 'src/backend/executor/functions.c')
0 files changed, 0 insertions, 0 deletions