On 06/09/2012 01:52 AM, Konstantin Mikhailov wrote:
Thanks alot. I've tried to play with work_mem and after few days
of the production testing pg behaves much better. See no more
files in the pgsql_tmp folder. pg processes consumes reasonable
memory, no swap operation any more. I've studied offic
Thanks alot. I've tried to play with work_mem and after few days
of the production testing pg behaves much better. See no more
files in the pgsql_tmp folder. pg processes consumes reasonable
memory, no swap operation any more. I've studied official pg
docs about work_mem an still have no idea which
if you have millions of files in data/pgsql_tmp it means that you're
using temporary tables (very) heavily .. or you've a huge sorting
activity (of large tables) and that the sort happens on disk (you can
verify that with an EXPLAIN ANALYZE of the query, you'll see something
like "external disk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
which fs with which settings are you using? What's the work_mem settings? Which
size do the files
have?
Depending on the answer of above questions I would suggest:
- - RAM disk, SSD or separate disk for pgsql_tmp
- - using xfs with
noatime,nodi
Hello.
Seen this already.
It looks like cross join + sort. Badly configured ORM tools like
Hibernate with multiple one-to-many relationships fetched with 'join'
strategy may produce such result.
Unfortunately I don't know if it's possible to protect from such a case
at server side.
Best rega
