what is the cmd？the default checkpoint method is spread,so pg_basebackup
will wait the checkpoint complete on the master.you can set the checkpoint
method to fast to avoid the waiting.
2014年10月7日 2:54 AM于 "Mike Blackwell" 写道：
> I'm seeing some strange behavior running pg_basebackup on 9.3.5. It
>
El lun, 06-10-2014 a las 10:54 -0400, Emi Lu escribió:
> Hello List,
>
> May I know will cause any potential performance issues for
> psql8.3 please?
> version (PostgreSQL 8.3.18 on x86_64-unknown-linux-gnu, compiled by
> GCC 4.1.2)
>
> E.g., got 10 idle connections for 10 days.
> select curr
I'm seeing some strange behavior running pg_basebackup on 9.3.5. It
appears that there are long pauses - up to a couple of minutes - between
relatively short bursts of disk activity.
I'm not noticing any lock requests outstanding. What might I be missing?
___
2014-10-06 11:54 GMT-03:00 Emi Lu :
> Hello List,
>
> May I know will cause any potential performance issues for psql8.3
> please?
> version (PostgreSQL 8.3.18 on x86_64-unknown-linux-gnu, compiled by GCC
> 4.1.2)
>
> E.g., got 10 idle connections for 10 days.
> select current_query from pg_sta
Hello List,
May I know will cause any potential performance
issues for psql8.3 please?
version (PostgreSQL 8.3.18 on x86_64-unknown-linux-gnu, compiled
by GCC 4.1.2)
E.g., got 10 idle connections for 10 days.
select current_query from
As I answered to Tom few moments ago:
>reducing 'random_page_cost' from 2 to 1 and increasing
'effective_cache_size' from 70% to 80% of RAM solved this at least on my
virtual sandbox.
I've observed same behaviour both on weak virtual machine and on the quite
powerfull stress test platform.
The firs
Thanks a lot, Tom,
reducing 'random_page_cost' from 2 to 1 and increasing 'effective_cache_size'
from 70% to 80% of RAM solved this at least on my virtual sandbox.
By the way, why increasing of cache only (with the same random_page_cost=2) can
lead to mergejoin selection?
On 5 October 2014 23:47,
