Search Postgresql Archives

Re: Optimizing select count query which often takes over 10 seconds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> It's sorting on disk. That's not going to be fast. Indeed, it's taking
> nearly all the time the query takes (4.4s for this step out of 4.5s for the
> query).

I've noticed that too, but what
does "sorting on disk" mean?

I have a lot of RAM (32 GB) ,
should I increase work_mem even more?
(it is currenlty 32 MB)

You can try increasing the amount of work_mem in your psql session only and see what amount helps. That way you don't need to permanently increase it for all your queries.
I'd start with 48 MB and increase in increments of 16 MB (as that's the size the sort operation claims to require on disk).

--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux