On Wed, Oct 12, 2022 at 6:47 AM Tom Lane wrote:
> However, that doesn't explain the downthread report that a
> VACUUM on the primary fixed it. What I suspect is that that
> caused some in-fact-dead index entries to get cleaned out.
Seems likely.
> But ... if the primary is allowed to vacuum awa
Peter Geoghegan writes:
> That's true, but it doesn't matter whether or not there are LP_DEAD
> bits set on the standby, since in any case they cannot be trusted when
> in Hot Standby mode. IndexScanDescData.ignore_killed_tuples will be
> set to false on the standby.
Hmm. I think that might brea
On Wed, 2022-10-12 at 10:51 +0200, Guillaume Lelarge wrote:
> Just finished my phone call. So, they definitely have their performance back.
> All they did was a VACUUM on two tables.
>
> If I understand correctly, during "normal" operations, some information is
> stored on the primary
> and sent
Le mer. 12 oct. 2022 à 08:56, Guillaume Lelarge a
écrit :
> Le mar. 11 oct. 2022 à 19:42, Guillaume Lelarge
> a écrit :
>
>> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
>> écrit :
>>
>>> On 2022-Oct-11, Tom Lane wrote:
>>>
>>> > Are there any tables in this query where extremal values of the
Le mar. 11 oct. 2022 à 19:42, Guillaume Lelarge a
écrit :
> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
> écrit :
>
>> On 2022-Oct-11, Tom Lane wrote:
>>
>> > Are there any tables in this query where extremal values of the join
>> > key are likely to be in recently-added or recently-dead rows
Le mer. 12 oct. 2022 à 06:08, Ron a écrit :
> On 10/11/22 22:35, Julien Rouhaud wrote:
> > On Tue, Oct 11, 2022 at 07:42:55PM +0200, Guillaume Lelarge wrote:
> >> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera
> a
> >> écrit :
> >>
> >>> On 2022-Oct-11, Tom Lane wrote:
> >>>
> Are there any t
On Tue, Oct 11, 2022 at 10:04 PM Tom Lane wrote:
> Do we propagate visibility-map bits to standbys?
Yes.
--
Peter Geoghegan
On Tue, Oct 11, 2022 at 9:27 AM Alvaro Herrera wrote:
> I remember having an hypothesis, upon getting a report of this exact
> problem on a customer system once, that it could be due to killtuple not
> propagating to standbys except by FPIs. I do not remember if we proved
> that true or not. I d
Julien Rouhaud writes:
> But since your customer recreated their standbys from scratch *after* that
> delete, all the nodes should have those hint bits set (Guillaume confirmed
> off-list that they used a fresh BASE_BACKUP). Note that Guillaume also
> confirmed off-list that the customer has chec
On 10/11/22 22:35, Julien Rouhaud wrote:
On Tue, Oct 11, 2022 at 07:42:55PM +0200, Guillaume Lelarge wrote:
Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
écrit :
On 2022-Oct-11, Tom Lane wrote:
Are there any tables in this query where extremal values of the join
key are likely to be in rec
On Tue, Oct 11, 2022 at 07:42:55PM +0200, Guillaume Lelarge wrote:
> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
> écrit :
>
> > On 2022-Oct-11, Tom Lane wrote:
> >
> > > Are there any tables in this query where extremal values of the join
> > > key are likely to be in recently-added or recent
Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
écrit :
> On 2022-Oct-11, Tom Lane wrote:
>
> > Are there any tables in this query where extremal values of the join
> > key are likely to be in recently-added or recently-dead rows? Does
> > VACUUM'ing on the primary help?
>
> I remember having an
On 2022-Oct-11, Tom Lane wrote:
> Are there any tables in this query where extremal values of the join
> key are likely to be in recently-added or recently-dead rows? Does
> VACUUM'ing on the primary help?
I remember having an hypothesis, upon getting a report of this exact
problem on a customer
Guillaume Lelarge writes:
> * The planner seems to read tables to generate the plans and/or select the
> right plan. Why does it do that? I thought it only reads indexes if needed,
> but it is quite clear it reads tables also.
I'm guessing to some extent, but it seems plausible that this is an
ar
14 matches
Mail list logo
