> "Amit" == Amit Kapila writes:
>> Presumably the problem is that the standby isn't authorized to change
>> the btree index's "entry is dead" bits,
Amit> I don't see anything like that in the code. We use _bt_killitems
Amit> to mark the items as dead and neither that function or any of i
On Thu, Jun 14, 2018 at 4:34 AM, Maksim Milyutin wrote:
> 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 wo
On Sun, Jun 10, 2018 at 1:19 AM, 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.
>
> Presumably the problem is that the standby isn't authorized to change
> the btree index's "entry
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 setti
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't
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.
Presumably the problem is that the standby isn't authorized to change
the btree index's "entry is dead" bits, so it's unable to prune index
entries previou
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
On hot standby I faced with the similar problem.
The following simple query:
SELECT array_to_json(array_agg(t)) from (
select *
from main.message m
join main.message_instance mi on m.message_id = mi.message_id
join main.channel_type ct on mi.channel_type_
Jerry Sievers writes:
> Tom Lane writes:
>> Oh, hmm, yeah it could be ye olde get_actual_variable_range() issue.
>> When this happens, are there perhaps a lot of recently-dead rows at either
>> extreme of the range of table1.source_id or table2.id?
> We noticed the cluster of interest had a rogu
Tom Lane writes:
> Pavel Stehule writes:
>
>> 2018-06-06 18:59 GMT+02:00 Jeremy Finzel :
>>> We have an odd scenario on one of our OLTP systems, which behaves the same
>>> way on a streamer, of a 700-1000ms planning time for a query like this:
>>> SELECT *
>>> FROM table1
>>> WHERE source_id IN
On 06/06/2018 09:59 AM, Jeremy Finzel wrote:
Hello -
We have an odd scenario on one of our OLTP systems, which behaves the
same way on a streamer, of a 700-1000ms planning time for a query like this:
SELECT *
FROM table1
WHERE source_id IN (SELECT id FROM table2 WHERE customer_id = $1);
The
Pavel Stehule writes:
> 2018-06-06 18:59 GMT+02:00 Jeremy Finzel :
>> We have an odd scenario on one of our OLTP systems, which behaves the same
>> way on a streamer, of a 700-1000ms planning time for a query like this:
>> SELECT *
>> FROM table1
>> WHERE source_id IN (SELECT id FROM table2 WHERE
2018-06-06 18:59 GMT+02:00 Jeremy Finzel :
> Hello -
>
> We have an odd scenario on one of our OLTP systems, which behaves the same
> way on a streamer, of a 700-1000ms planning time for a query like this:
>
> SELECT *
> FROM table1
> WHERE source_id IN (SELECT id FROM table2 WHERE customer_id =
On Wed, Jun 6, 2018 at 1:13 PM, Jeremy Finzel wrote:
>
>
> On Wed, Jun 6, 2018 at 12:12 PM, Tom Lane wrote:
>
>> Jeremy Finzel writes:
>> > We have an odd scenario on one of our OLTP systems, which behaves the
>> same
>> > way on a streamer, of a 700-1000ms planning time for a query like this:
On Wed, Jun 6, 2018 at 12:12 PM, Tom Lane wrote:
> Jeremy Finzel writes:
> > We have an odd scenario on one of our OLTP systems, which behaves the
> same
> > way on a streamer, of a 700-1000ms planning time for a query like this:
>
> > SELECT *
> > FROM table1
> > WHERE source_id IN (SELECT id
Jeremy Finzel writes:
> We have an odd scenario on one of our OLTP systems, which behaves the same
> way on a streamer, of a 700-1000ms planning time for a query like this:
> SELECT *
> FROM table1
> WHERE source_id IN (SELECT id FROM table2 WHERE customer_id = $1);
Hm. Is this the first query
16 matches
Mail list logo
