Цитат от Robert Haas <robertmhaas@xxxxxxxxx>:
2009/9/14 <tv@xxxxxxxx>:
It seems there's something very wrong - the plans are "equal" but in the
first case the results (actual time) are multiplied by 100. Eithere there
is some sort of cache (so the second execution is much faster), or the
system was busy during the first execution, or there is something wrong
with the hardware.
I think you should run this query more than twice. If it's slow the
first time and fast every time for many executions after that, then
it's probably just the data getting loaded into the OS cache (or
shared buffers). If it's bouncing back and forth between fast and
slow, you might want to check whether your machine is swapping.
I did it many times. Alter the first atempt it works fast, but after a
couple of minutes ( I think after changing the data in cache) the
query is working also very slow.
I do not see any swap on OS.
It might also be helpful to post all the uncommented settings from
your postgresql.conf file.
postgresql.conf :
max_connections = 2000
shared_buffers = 1800MB
temp_buffers = 80MB
work_mem = 120MB
maintenance_work_mem = 100MB
max_fsm_pages = 404800
max_fsm_relations = 5000
max_files_per_process = 2000
wal_buffers = 64MB
checkpoint_segments = 30
effective_cache_size = 5000MB
default_statistics_target = 800
All the rest are default parameters.
Ivan.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
-------------------------------------
Powered by Mail.BG - http://mail.bg
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
