Re: count * performance issue - Mailing list pgsql-performance

From A. Kretschmer
Subject Re: count * performance issue
Date
Msg-id 20080306063643.GB21084@a-kretschmer.de
Whole thread Raw
In response to Re: count * performance issue  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: count * performance issue
List pgsql-performance
am  Thu, dem 06.03.2008, um  1:26:46 -0500 mailte Mark Mielke folgendes:
>
>
>         There aren't a general solution. If you realy need the exact count of
>         tuples than you can play with a TRIGGER and increase/decrease the
>         tuple-count for this table in an extra table.
>
>
> Of course, this means accepting the cost of obtaining update locks on the count
> table.
>
> The original poster should understand that they can either get a fast estimated
> count, or they can get a slow accurate count (either slow in terms of select
> using count(*) or slow in terms of updates using triggers and locking).
>
> Other systems have their own issues. An index scan may be faster than a table
> scan for databases that can accurately determine counts using only the index,

No. The current index-implementation contains no information about the
row-visibility within the current transaction. You need to scan the
whole data-table to obtain if the current row are visible within the
current transaction.


> but it's still a relatively slow operation, and people don't normally need an
> accurate count for records in the range of 100,000+? :-)

right.


Andreas
--
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

pgsql-performance by date:

Previous
From: "Shoaib Mir"
Date:
Subject: Re: count * performance issue
Next
From: "sathiya psql"
Date:
Subject: Re: count * performance issue