Zach Calvert wrote:
Still getting a seq scan after doing vacuum analyze. Any other ideas?
Try CLUSTERing the table on the (leaderboardid, active, score) index.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-performance mailing list (pgsql-performance@p
Still getting a seq scan after doing vacuum analyze. Any other ideas?
2009/5/27 Grzegorz Jaśkiewicz :
> you have to vacuum analyze after you've created index, afaik.
> No, count(*) is still counting rows.
>
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make ch
you have to vacuum analyze after you've created index, afaik.
No, count(*) is still counting rows.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
I'm running the inserts now via a JDBC call I have, which is then
followed up by the query I'm showing and a few others. I have run
tests on all of the others, and all others run index scans and are
very fast, 10 ms or less. This one started at 2 milliseconds when the
table is empty and is up to
The plan ought to be different when there are more scores and the table is
analyzed and your statistics target is high enough. At this point you don't
have enough data to merit doing anything but a seq scan. The overhead is
simply not worth it.
You could try inserting a lot more rows. I'd creat
try creating index on all three columns.
Btw, 38ms is pretty fast. If you run that query very often, do prepare
it, cos I reckon it takes few ms to actually create plan for it.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http
So Google hasn't been helpful and I'm not entirely sure what to look
for in the mailing lists to find the answer to my problem, so here
goes.
I have a query and I have run
explain analyze
select count(*)
from score
where leaderboardid=35 and score <= 6841 and active
The result is
"Aggregate (co
