Albe Laurenz wrote: > Alban Hertroys wrote: >> A. Kretschmer wrote: >>> Again: an index can't help! Because of MVCC: 'select count(*)' > without >>> WHERE-condition forces an seq. table-scan. >> That has very little to do with MVCC. >> >> [...] For that it makes no difference whether a seq >> scan or an index scan is performed - both cases need to check at the >> record level whether it's visible (where the seq scan is >> already looking at the actual record, of course). > > If you do not use MVCC (say, you use DB2), you need not check > the record itself because if it is there (which it is if there > is an index entry), it will be 'visible'. Still, that's not because of MVCC, but because of the way it is implemented in PostgreSQL. There has been talk in the past (regularly) about why the MVCC information is not in the index and whether it should be, see the ML archives. Besides, there are still many situations where a sequential scan (whether for count(*) or not) is faster than an index scan, no matter whether you have MVCC or not. As I said, MVCC has little to do with it. The real problem is that in postgres you cannot tell from an index whether a record is visible or not, while you can in DB2 (because it has an index entry or not). >> I pleed not guilty ;) > > Declined, sorry. Overruled, sorry. -- Alban Hertroys alban@xxxxxxxxxxxxxxxxx magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World // ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
