Обсуждение: select count(*) from a large table is very slow
I have a ~30 milliow row table, select count(*) from this table is very very very slow...
How dow I get it run faster?
Thanks,
Jessica
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
How dow I get it run faster?
Thanks,
Jessica
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
Make a summary table and select from there instead. Ken On Fri, May 18, 2007 at 06:15:25AM -0700, Jessica Richard wrote: > I have a ~30 milliow row table, select count(*) from this table is very very very slow... > > How dow I get it run faster? > > Thanks, > Jessica > > > --------------------------------- > We won't tell. Get more on shows you hate to love > (and love to hate): Yahoo! TV's Guilty Pleasures list.
On 5/18/07, Jessica Richard <rjessil@yahoo.com> wrote: > I have a ~30 milliow row table, select count(*) from this table is very very > very slow... Yes, see the topic "Much Ado about COUNT(*)" > How dow I get it run faster? Unfortunately, aside from reducing the size of the table, you can't. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 5/18/07, Kenneth Marshall <ktm@rice.edu> wrote: > Make a summary table and select from there instead. Yes, a summary table updated by triggers is the only way to have correct numbers... but you also pay the overhead of maintaining those numbers on every INSERT/UPDATE statement. If you just need *reasonable* guesstimates, use reltuples in pg_class after an analyze. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
2007/5/18, Jonah H. Harris <jonah.harris@gmail.com>: > Yes, a summary table updated by triggers is the only way to have > correct numbers... but you also pay the overhead of maintaining those > numbers on every INSERT/UPDATE statement. If you just need > *reasonable* guesstimates, use reltuples in pg_class after an analyze. Oops... INSERT or DELETE... :) And remember that if using TRUNCATE, it will not run your trigger and you will need to reset the counter manually. Regards... -- Daniel Cristian Cruz
On 5/18/07, Daniel Cristian Cruz <danielcristian@gmail.com> wrote: > Oops... INSERT or DELETE... :) Heh, yeah... doh! > And remember that if using TRUNCATE, it will not run your trigger and > you will need to reset the counter manually. Correct. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/