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
On Wed, 12 Oct 2022 at 13:06, Klint Gore wrote:
> Limit (cost=0.56..28349.28 rows=1 width=4) (actual time=0.039..0.040 rows=1
> loops=1)
> -> Unique (cost=0.56..28349.28 rows=1 width=4) (actual time=0.039..0.039
> rows=1 loops=1)
> -> Index Only Scan using idx on tbl (cost=0.56..2
From: Bruce Momjian Sent: Wednesday, 12 October 2022 1:30 AM
>On Tue, Oct 11, 2022 at 09:59:43AM -0400, Tom Lane wrote:
>> David Rowley writes:
>> > It feels like something is a bit lacking in our cost model here. I'm
>> > just not sure what that is.
>>
>> The ex
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
Hello,
My customer has a really weird planner issue on a standby.
First, the context. There's a primary, and two standbys, all on a 11.8
release. (I know this isn't the latest release for the v11 branch.) The
cluster is 5.5TB. The PostgreSQL configuration is the same on all servers.
pg_db_role_se
On Tue, Oct 11, 2022 at 09:59:43AM -0400, Tom Lane wrote:
> David Rowley writes:
> > It feels like something is a bit lacking in our cost model here. I'm
> > just not sure what that is.
>
> The example you show is the same old problem that we've understood for
> decades: for cost-estimation purpo
David Rowley writes:
> It feels like something is a bit lacking in our cost model here. I'm
> just not sure what that is.
The example you show is the same old problem that we've understood for
decades: for cost-estimation purposes, we assume that matching rows
are more or less evenly distributed
On Tue, 11 Oct 2022 at 16:13, gzh wrote:
> new=# explain analyze select 2 from analyze_word_reports where (cseid = 94)
> limit 1;
> Limit (cost=0.00..0.43 rows=1 width=4) (actual time=2156.964..2156.966
> rows=1 loops=1)
>-> Seq Scan on analyze_word_reports (cost=0.00..528550.75 rows=122
On Tue, 11 Oct 2022 at 22:52, Josef Šimánek wrote:
> This can make some queries fail since there will be no way to gather
> data without seqscan.
Disabling enable_seqscan only adds a const penalty to Seq Scans. It
does not outright disallow them altogether.
Having said that, having Paths with th
út 11. 10. 2022 v 11:17 odesílatel gzh napsal:
>
> Thank you for all your assistance.
>
>
> By communicating with my customer, we have adopted the following solution to
> fix the problem.
>
>
> set enable_seqscan = off
>
This can make some queries fail since there will be no way to gather
data wi
Thank you for all your assistance.
By communicating with my customer, we have adopted the following solution to
fix the problem.
set enable_seqscan = off
At 2022-10-11 16:21:42, "Pavel Stehule" wrote:
út 11. 10. 2022 v 10:01 odesílatel gzh napsal:
Thank you for pro
út 11. 10. 2022 v 10:01 odesílatel gzh napsal:
> Thank you for providing the requested information.
>
>
> The WebSite has been used for many years, and this upgrade is only a
> version upgrade of the PostgreSQL database.
> My customer does not want to modify the SQL because it will increase the
>
Thank you for providing the requested information.
The WebSite has been used for many years, and this upgrade is only a version
upgrade of the PostgreSQL database.
My customer does not want to modify the SQL because it will increase the cost
of the project(All SQL that contains a LIMIT claus
21 matches
Mail list logo
