On 03/08/16 02:27, Robert Haas wrote:
Personally, I think that incremental surgery on our current heap
format to try to fix this is not going to get very far. If you look
at the history of this, 8.3 was a huge release for timely cleanup of
dead tuple. There was also significant progress in 8.4 as a result of
5da9da71c44f27ba48fdad08ef263bf70e43e689. As far as I can recall, we
then made no progress at all in 9.0 - 9.4. We made a very small
improvement in 9.5 with 94028691609f8e148bd4ce72c46163f018832a5b, but
that's pretty niche. In 9.6, we have "snapshot too old", which I'd
argue is potentially a large improvement, but it was big and invasive
and will no doubt pose code maintenance hazards in the years to come;
also, many people won't be able to use it or won't realize that they
should use it. I think it is likely that further incremental
improvements here will be quite hard to find, and the amount of effort
will be large relative to the amount of benefit. I think we need a
new storage format where the bloat is cleanly separated from the data
rather than intermingled with it; every other major RDMS works that
way. Perhaps this is a case of "the grass is greener on the other
side of the fence", but I don't think so.
Yeah, I think this is a good summary of the state of play.
The only other new db development to use a non-overwriting design like
ours that I know of was Jim Starky's Falcon engine for (ironically)
Mysql 6.0. Not sure if anyone is still progressing that at all now.
I do wonder if Uber could have successfully tamed dead tuple bloat with
aggressive per-table autovacuum settings (and if in fact they tried),
but as I think Robert said earlier, it is pretty easy to come up with a
highly update (or insert + delete) workload that makes for a pretty ugly
bloat component even with real aggressive autovacuuming.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
