Mindaugas Riauba wrote:
When a row is orphaned it's added to a list of possibly available rows.
When a new row is needed the list of possible rows is examined and the
first one with a transaction id less then the lowest running transaction
id is chosen to be the new row? These rows can be in a heap so it's
really fast to find one.
This is the long-term plan. However, it's actually a lot harder than it
sounds. Patches welcome.
Some ETA? Since that would be the most welcome addition for us. We
have few very heavily updated databases where table bloat and constant
vacuuming is killing performance.
How often are you vacuuming (the definition of 'constantly' tends to
vary)? Are you vacuuming the whole database each time? If so, identify
which tables are being updated frequently, and vacuum those often.
Vacuum other tables less frequently.
Also, are you you using VACUUM FULL (if so, you certainly don't want to be).
--
Brad Nicholson 416-673-4106 [EMAIL PROTECTED]
Database Administrator, Afilias Canada Corp.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match