Tom Lane escribió: > Alvaro Herrera <alvhe...@commandprompt.com> writes: > > Another weird consequence of this is that it bails out if it finds a > > tuple larger than it can fit in one of the earlier pages; if there's > > dead space to be compacted before that, it's not compacted. > > I don't find a lot wrong with that. The code defines its purpose as > being to shorten the table file length. Once it hits a page that > can't be emptied, it cannot shorten the file any further, so why > shouldn't it stop?
All that work, and it wasn't capable of defragging the other pages? At the very least it could register them in the FSM. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
