Apologises if I've missed something, but isn't that the same xmin that ODBC
uses for row versioning?
- Stuart
> Currently, the XMIN/XMAX command counters are used only by the current
> transaction, and they are useless once the transaction finishes and take
> up 8 bytes on disk.
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Irrelevant, not to mention already done ...
> Do you mean that we already can do just analyze ?
In development sources, yes. See
http://www.ca.postgresql.org/devel-corner/docs/postgres/sql-analyze.html
regards, tom lane
---
mlw <[EMAIL PROTECTED]> writes:
> My only suggestion would be to store some information in the statistics about
> whether or not, and how bad, a table needs to be vacuumed.
I was toying with the notion of using the FSM to derive that info,
somewhat indirectly to be sure (since what the FSM could
Heck ya...
> I wonder if cache failures should be what drives the vacuum daemon to
> vacuum a table? Sort of like, "Hey, someone is asking for free pages
> for that table. Let's go find some!" That may work really well.
> Another advantage of centralization is that we can record update/delete
