Christopher Browne <[EMAIL PROTECTED]> writes: > In the last exciting episode, [EMAIL PROTECTED] (Dror Matalon) wrote: > > I was answering an earlier response that suggested that maybe the actual > > counting took time so it would take quite a bit longer when there are > > more rows to count.
That was my theory. I guess it's wrong. There is other work involved in processing a record, but i'm surprised it's as long as the work to actually pull the record from kernel and check if it's visible. > Well, if a "where clause" allows the system to use an index to search > for the subset of elements, that would reduce the number of pages that > have to be examined, thereby diminishing the amount of work. it's not. therein lies the mystery. > Why don't you report what EXPLAIN ANALYZE returns as output for the > query with WHERE clause? That would allow us to get more of an idea > of what is going on... He did, right at the start of the thread. For a 1 million record table without he's seeing select 1 from tab select count(*) from tab being comparable with only a slight delay for the count(*) whereas select 1 from tab where c < 1000 select count(*) from tab where c < 1000 are much faster even though they still use a sequential scan. I'm puzzled why the where clause speeds things up as much as it does. -- greg ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
