On Feb 2, 2007, at 1:41 PM, Simon Riggs wrote:
On Thu, 2007-02-01 at 23:57 -0600, Jim Nasby wrote:
Has anyone actually measured the performance overhead of storing
visibility info in indexes? I know the space overhead sounds
daunting, but even if it doubled the size of the index in many cases
that'd still be a huge win over having to scan the heap as well as
the index (esp. for things like count(*)). There would also be
overhead from having to update the old index tuple, but for the case
of updates you're likely to need that page for the new index tuple
I know this wouldn't work for all cases, but ISTM there are many
cases where it would be a win.
It would prevent any optimization that sought to avoid inserting rows
into the index each time we perform an UPDATE. Improving UPDATE
performance seems more important than improving count(*), IMHO.
That depends on what you're doing; a large read-mostly table would
likely see a lot of benefit from being able to do covering index scans.
Of course this would have to be optional; there's lots of cases where
you wouldn't want the added index size.
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(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