Thread: count(*) optimization
Hi
I have trouble executing count(*) statement.
On a large dataset it takes quite a while to return result.
Is there any other way to get number of tupples in relation
or is the only way to optimize count() function to index it?
thanks
Nikola
On Wed, Jan 08, 2003 at 17:04:40 +0100, Nikola Ivacic <nikola@rs-pi.com> wrote: > Hi > > I have trouble executing count(*) statement. > On a large dataset it takes quite a while to return result. > Is there any other way to get number of tupples in relation > or is the only way to optimize count() function to index it? Indexes won't help count. If you retrieve counts a lot more than you do updates that will change their value, then you may want to keep the counts in another table and use triggers to keep them updated.
The problem is in other software I use, witch uses count(*) function to display relation properties pgAdmin II phpPgAdmin Nikola ----- Original Message ----- From: "Bruno Wolff III" <bruno@wolff.to> To: "Nikola Ivacic" <nikola@rs-pi.com> Cc: <pgsql-sql@postgresql.org> Sent: Wednesday, January 08, 2003 5:22 PM Subject: Re: [SQL] count(*) optimization > On Wed, Jan 08, 2003 at 17:04:40 +0100, > Nikola Ivacic <nikola@rs-pi.com> wrote: > > Hi > > > > I have trouble executing count(*) statement. > > On a large dataset it takes quite a while to return result. > > Is there any other way to get number of tupples in relation > > or is the only way to optimize count() function to index it? > > Indexes won't help count. > > If you retrieve counts a lot more than you do updates that will change their > value, then you may want to keep the counts in another table and use > triggers to keep them updated. >
I am not sure pgAdmin uses count(*) and I didn't have time to check phpPgAdmin also, I presumed it from similarly slow response I get in psql Nikola ----- Original Message ----- From: "Ian Harding" <ianh@tpchd.org> To: <nikola@rs-pi.com>; <bruno@wolff.to> Cc: <PGSQL-sql@postgresql.org> Sent: Wednesday, January 08, 2003 5:20 PM Subject: Re: [SQL] count(*) optimization Bummer. I seem to remember PGAccess using the numbers generated by ANALYZE to show the number of records. I noticed it was inaccurate until you ran a vaccum. I guess pgAdmin chose accuracy over speed in this case. Ian Harding Programmer/Analyst II Tacoma-Pierce County Health Department iharding@tpchd.org (253) 798-3549 >>> "Nikola Ivacic" <nikola@rs-pi.com> 01/08/03 08:15AM >>> The problem is in other software I use, witch uses count(*) function to display relation properties pgAdmin II phpPgAdmin Nikola ----- Original Message ----- From: "Bruno Wolff III" <bruno@wolff.to> To: "Nikola Ivacic" <nikola@rs-pi.com> Cc: <pgsql-sql@postgresql.org> Sent: Wednesday, January 08, 2003 5:22 PM Subject: Re: [SQL] count(*) optimization > On Wed, Jan 08, 2003 at 17:04:40 +0100, > Nikola Ivacic <nikola@rs-pi.com> wrote: > > Hi > > > > I have trouble executing count(*) statement. > > On a large dataset it takes quite a while to return result. > > Is there any other way to get number of tupples in relation > > or is the only way to optimize count() function to index it? > > Indexes won't help count. > > If you retrieve counts a lot more than you do updates that will change their > value, then you may want to keep the counts in another table and use > triggers to keep them updated. > ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Nikola, > I am not sure pgAdmin uses count(*) and I didn't have time to check > phpPgAdmin also, I presumed it from similarly slow response I get in > psql Well, pgAdmin and phpPgAdmin have their own mailing lists. I'd suggest posting there. Ideally, these programs should have an option that lets you use the Analyze stats instead of a real count if you want speed over accuracy. If nobody requests it, though, neither development team is likely to consider it. Of course, it's also possible that these interfaces are slow for lots of other reasons. For example, I've found pgAdminII to be sluggish on a large, busy network because MS-ODBC is quite vulnerable to traffic conflicts. And phpPgAdmin, at least several versions ago, had a tendency to issue a seperate query for each single bit of information, mySQL-style (they may have fixed this, though). -Josh Berkus