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
ú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 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 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
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
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
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, 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
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
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
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
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
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
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
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 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
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 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
On Tue, Oct 11, 2022 at 10:04 PM Tom Lane wrote:
> Do we propagate visibility-map bits to standbys?
Yes.
--
Peter Geoghegan
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
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
21 matches
Mail list logo
