Robert,
> Uh, no it doesn't. It only requires you to be more aggressive about
> vacuuming the transactions that are in the aborted-XIDs array. It
> doesn't affect transaction wraparound vacuuming at all, either
> positively or negatively. You still have to freeze xmins before they
> flip from being in the past to being in the future, but that's it.
Sorry, I was trying to say that it's similar to the freeze issue, not
that it affects freeze. Sorry for the lack of clarity.
What I was getting at is that this could cause us to vacuum
relations/pages which would otherwise never be vaccuumed (or at least,
not until freeze). Imagine a very large DW table which is normally
insert-only and seldom queried, but once a month or so the insert aborts
and rolls back.
I'm not saying that your proposal isn't worth testing. I'm just saying
that it may prove to be a net loss to overall system efficiency.
>> If we ever handle that, would #6 be a moot point, or do you think
>> > it's still a significant issue?
Kevin, the case which your solution doesn't fix is the common one of
"log tables" which keep adding records continuously, with < 5% inserts
or updates. That may seem like a "corner case" but such a table,
partitioned or unpartitioned, exists in around 1/3 of the commercial
applications I've worked on, so it's a common pattern.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com