On Tue, Apr 28, 2015 at 1:53 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> Because in those cases it would be trivial to drop XMIN out of the tuple
> headers. For a warehouse with narrow rows that could be a significant win.
> Moreso, we could also move XMAX to the page level if we accept that if we
> need to invalidate any tuple we'd have to move all of them. In a warehouse
> situation that's probably OK as well.
You have a funny definition of "trivial". If you start looking
through the code you'll see that anything that changes the format of
the tuple header is a very large undertaking. And the bit about "if
we invalidate any tuple we'd need to move all of them" doesn't really
make any sense; we have no infrastructure that would allow us "move"
tuples like that. A lot of people would like it if we did, but we
don't.
> That said, I don't think this is the first place to focus for reducing our
> on-disk format; reducing cleanup bloat would probably be a lot more useful.
Sure; changing the on-disk format is a different project that tracking
the frozen parts of a table, which is what this thread started out
being about, and nothing you've said since then seems to add or
detract from that. I still think the best way to do it is to make the
VM carry two bits per page instead of one.
> Did you or Jan have more detailed info from the test he ran about where our
> 80% overhead was ending up? That would remove a lot of speculation here...
We have more detailed information on that, but (1) that's not a very
specific question and (2) it has nothing to do with freeze avoidance,
so I'm not sure why you are asking on this thread. Let's try not to
get sidetracked from the well-defined proposal that just needs to be
implemented to speculation about major changes in completely unrelated
areas.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company