Heikki Linnakangas wrote:
I have some suggestions which I'll post separately,


A significant chunk of the complexity and new code in the patch comes from pruning hot chains and reusing the space for new updates. Because we can't reclaim dead space in the page like a VACUUM does, without holding the vacuum lock, we have to deal with pages that contain deleted tuples, and be able to reuse them, and keep track of the changes in tuple length etc.

A much simpler approach would be to try to acquire the vacuum lock, and compact the page the usual way, and fall back to a cold update if we can't get the lock immediately.

The obvious downside of that is that if a page is continuously pinned, we can't HOT update tuples on it. Keeping in mind that the primary use case for HOT is largeish tables, small tables are handled pretty well by autovacuum, chances are pretty good that you can get a vacuum lock when you need it.

Thoughts?

I'm looking for ways to make the patch simpler and less invasive. We may want to put back some of this stuff, or come up with a more clever solution, in future releases, but right let's keep it simple.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to