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@magproductions.nl
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 //
