Re: Slow planning time for simple query - Mailing list pgsql-general

From Maksim Milyutin
Subject Re: Slow planning time for simple query
Date
Msg-id 4d61f569-c781-9066-c6b8-471e963d7759@gmail.com
Whole thread Raw
In response to Re: Slow planning time for simple query  (Maksim Milyutin <milyutinma@gmail.com>)
Responses Re: Slow planning time for simple query  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Slow planning time for simple query  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-general

13.06.2018 12:40, Maksim Milyutin wrote:

On 09.06.2018 22:49, Tom Lane wrote:

Maksim Milyutin <milyutinma@gmail.com> 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't propagate to the
standby.)

I have verified the number dead item pointers (through pageinspect extension) in the first leaf page of index participating in query ('main.message_instance_pkey') on master and slave nodes and have noticed a big difference.

SELECT * FROM monitoring.bt_page_stats('main.message_instance_pkey', 3705);

On master:

 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
  3705 | l    |          1 |         58 |            24 |      8192 |      6496 |         0 |      3719 |    0 |         65

On standby:

 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
  3705 | l    |         59 |          0 |            24 |      8192 |      6496 |         0 |      3719 |    0 |          1



In this point I want to highlight the issue that the changes in lp_flags bits (namely, set items as dead) for index item pointers doesn't propagate from master to replica in my case. As a consequence, on standby I have live index items most of which on master are marked as dead. And my queries on planning stage are forced to descent to heap pages under get_actual_variable_range execution that considerately slows down planning.

Is it bug or restriction of implementation or misconfiguration of WAL/replication?

-- 
Regards,
Maksim Milyutin

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Replica string comparsion issue
Next
From: Daniel Lagerman
Date:
Subject: Impact of multixact "members" limit exceeded