The plan used the way to bypass 'order by' via index scan backward. The
query should scan tables through the index and do nl join the other tables
while it finds 10 rows that meet the condition MCL.ctid = '01010002759'.
The problem is the rows that meets your condition is very rarely founded so
the
Hi,
I started replicating my Postgres9.1.3 server on Friday, and it seems to be
working well.
The master server database is quite large (somewhere in the order of 85GB) so
the rsync to copy the base_backup took a while to complete.
However, looking at the log files and 'ps' I'm wondering if the
On Mon, Jun 25, 2012 at 9:19 AM, Kevin Grittner
wrote:
> Mike Broers wrote:
>
>> Ultimately the hosting service restored the files that they had
>> not brought over during their maintenance migration and we started
>> up ok. So that was a relief.
>
> +1
>
>> We had archived log files but it did
On 06/25/2012 11:00 PM, Radovan Jablonovsky wrote:
Thanks for response,
How were the connections refused (error message)?
2012-06-13 13:45:38.809 MDT [25172]: [1-1] FATAL: remaining
connection slots are reserved for non-replication superuser connections
2012-06-13 13:45:38.889 MDT [25173]: [1-
Mike Broers wrote:
> Ultimately the hosting service restored the files that they had
> not brought over during their maintenance migration and we started
> up ok. So that was a relief.
+1
> We had archived log files but it did not appear that the archive
> destination was caught up with the
Thanks for response,
How were the connections refused (error message)?
2012-06-13 13:45:38.809 MDT [25172]: [1-1] FATAL: remaining connection
slots are reserved for non-replication superuser connections
2012-06-13 13:45:38.889 MDT [25173]: [1-1] FATAL: remaining connection
slots are reserved for
Ultimately the hosting service restored the files that they had not brought
over during their maintenance migration and we started up ok. So that was
a relief.
We had archived log files but it did not appear that the archive
destination was caught up with the xlog the cluster was complaining abou
wangqi wrote:
> An SQL execution is very slow.
> What can I do to makes it faster。
Without knowing more about the version of PostgreSQL, your PostgreSQL
configuration, your schema (including indexes), and your hardware,
it's hard to give advice.
http://wiki.postgresql.org/wiki/SlowQueryQuest
Radovan Jablonovsky wrote:
> Could you please help with this peculiar problem?
>
>
> In PostgreSQL log occurred this message:
>
> 2012-06-13 12:58:45.876 MDT [17536]: [1-1] FATAL: terminating
autovacuum process due to administrator
> command
> The server worked for 48 minutes after and then it
