Tom Lane wrote
>
>I did some experimentation here and found a rather surprising
>dependency: the time to delete a bunch of data is pretty much
>directly proportional to the disk space it occupies. This says
>that we're paying through the nose for having XLOG make copies
>of about-to-be-modified pages.
>
At least now I know I wasn't imagining things.... :-)
Which brings up the question, what is the best way to deal with many
thousands of variable-length binary chunks. Net input == net output
over the course of a day. The new vacuum should help (both lo_ and
toasted tables take a long time to vacuum full), but I'm running into
the "Hotel California" situation. Data goes in fast, but can't be
deleted fast enough to keep the database from continuously growing
in size.
