,
Maksim Milyutin
On 19.12.2019 18:08, Fabio Ugo Venchiarutti wrote:
On 19/12/2019 13:58, Maksim Milyutin wrote:
On 19.12.2019 14:04, Andrey Borodin wrote:
Hi!
Hi!
FYI, this topic was up recently in -hackers
https://www.postgresql.org/message-id/caeet0zhg5off7iecby6tzadh1moslmfz1hlm311p9vot7z
synchronizes
its changes with all sync replicas as it's implemented in Stolon
https://github.com/sorintlab/stolon/blob/master/doc/syncrepl.md#handling-postgresql-sync-repl-limits-under-such-circumstances
.
Best regards,
Maksim Milyutin
cess checkpointer process tries to flush and as a
consequence to touch each buffer cell therefore its RSS approaches to
local allocated memory plus shared_buffers.
If you want to know the real local memory consumption you may to use
python utility *smem* to see unshared local memory size.
--
Regards,
Maksim Milyutin
13.06.2018 12:40, Maksim Milyutin wrote:
On 09.06.2018 22:49, Tom Lane wrote:
Maksim Milyutin writes:
On hot standby I faced with the similar problem.
...
is planned 4.940 ms on master and *254.741* ms on standby.
(I wonder though why, if you executed the same query on the master,
its
facilitate the search for the cause of your problem.
--
Regards,
Maksim Milyutin
On 09.06.2018 22:49, Tom Lane wrote:
Maksim Milyutin writes:
On hot standby I faced with the similar problem.
...
is planned 4.940 ms on master and *254.741* ms on standby.
(I wonder though why, if you executed the same query on the master,
its setting of the index-entry-is-dead bits didn&#
On 09.06.2018 21:49, Maksim Milyutin wrote:
On hot standby I faced with the similar problem.
Sorry, the problem in question is described here
https://www.postgresql.org/message-id/22136.1528312205%40sss.pgh.pa.us
--
Regards,
Maksim Milyutin
nd main.message_instance) on
master node resolves the problem somehow but its often execution slows
down all queries and generally increases IO.
Is there any case to overcome the problem or it's fundamental issue and
necessary to rewrite the query to simplify planning?
--
Regards,
Maksim Milyutin
