ANALYZE pg_class; doesn't help
also, query is from "Hasura", so I don't have much room to maneuver
On Tue, 21 May 2024 at 16:18, Tom Lane wrote:
> =?UTF-8?B?U2HFoW8gR2FudGFy?= writes:
> > thanks for the info, but is there any solution, given that it's system
> > tables?
>
> Given the complexity
Oops. This means major rewrite of my backup procedure. Thanks for pointing
this out. I will likely just switch to pg_basebackup. What I have is something
old and gnarly from the days of psql version 8.
From: David G. Johnston
Sent: Tuesday, May 21, 2024
On Tuesday, May 21, 2024, David G. Johnston
wrote:
>
> On Tue, May 21, 2024, 17:29 Dmitry O Litvintsev wrote:
>
>>
>> This is not just amusing, it is breaking my backup script after update
>> from 11 to 15 (and change from pg_{start,stop}_backup to
>> pg_backup_{start_stop})
>>
>
>
> Yep, nowaday
On Tue, May 21, 2024, 17:29 Dmitry O Litvintsev wrote:
> Hi,
>
> I am observing the following error which confuses me:
>
> # psql -U postgres template1 -c "checkpoint; select
> pg_backup_start('${dest}.tar.Z', true)"
> CHECKPOINT
> pg_backup_start
> -
> 17BF7/3009498
> (1 row)
Hi,
I am observing the following error which confuses me:
# psql -U postgres template1 -c "checkpoint; select
pg_backup_start('${dest}.tar.Z', true)"
CHECKPOINT
pg_backup_start
-
17BF7/3009498
(1 row)
# psql -U postgres template1 -c "select pg_backup_stop(true)"
ERROR: b
On 5/21/24 13:44, HORDER Philip wrote:
Classified as: {OPEN}
2024-05-15 03:31:31.290 GMT [4556]: [3-1]
db=lfm,user=superuser,app=[unknown],client=::1 LOG: connection
authorized: user=superuser database=lfm application_name=pg_restore
That would be the lfm database being restored.
What does th
Hi All,
I'd like to understand what's happening here and whether there is
anything I can do to improve the situation.
PostgreSQL v11.22 (yeah, I know. Needs upgrade)
The following 3 autovacuum log entries show a vacuum of an append only
table that has not had any changes since the end of 5/1
Classified as: {OPEN}
2024-05-15 03:31:31.290 GMT [4556]: [3-1]
db=lfm,user=superuser,app=[unknown],client=::1 LOG: connection
authorized: user=superuser database=lfm application_name=pg_restore
> That would be the lfm database being restored.
> What does the log show after that as pertains to a
Hi Kashif, just to clarify my question, are you saying that the I/O from
parallel workers is recorded into the "background worker" entry of
pg_stat_io?
Thanks,
Dimitris
On Wed, 15 May 2024, Kashif Zeeshan wrote:
Hi
parallel worker are used for parallel execution of the queries and you can fin
On 5/21/24 9:29 AM, HORDER Philip wrote:
Classified as: {OPEN}
I am having a hard time figuring out how both of the above can be true.
Dropping and recreating the database would wipe out the statistics.
We have multiple databases on the one Postgres server.
The 'postgres' database contains
On 5/21/24 9:29 AM, HORDER Philip wrote:
Classified as: {OPEN}
I am having a hard time figuring out how both of the above can be true.
Dropping and recreating the database would wipe out the statistics.
We have multiple databases on the one Postgres server.
The 'postgres' database contains
Classified as: {OPEN}
> I am having a hard time figuring out how both of the above can be true.
> Dropping and recreating the database would wipe out the statistics.
We have multiple databases on the one Postgres server.
The 'postgres' database contains our main application, with tables in schema
On 5/21/24 06:00, HORDER Philip wrote:
Classified as: {OPEN}
Assuming clean shutdowns the statistics will survive restarts. They would be
wiped when you drop a database and start over, have an unclean shutdown or you
use one of the reset functions...
Yes, stats are permanent, but are not be
=?UTF-8?B?U2HFoW8gR2FudGFy?= writes:
> thanks for the info, but is there any solution, given that it's system
> tables?
Given the complexity of the query, I wonder if you're running into
problems with join_collapse_limit/from_collapse_limit preventing
the planner from considering all options.
Al
Classified as: {OPEN}
> Assuming clean shutdowns the statistics will survive restarts. They would be
> wiped when you drop a database and start over, have an unclean shutdown or
> you use one of the reset functions...
Yes, stats are permanent, but are not being updated.
We don't use any of the
sorry...
SELECT COALESCE(Json_agg(Row_to_json(info)), '[]' :: JSON) AS TABLES
FROM
(WITH partitions AS
(SELECT array
(WITH partitioned_tables AS
(SELECT array
(SELECT oid
FROM pg_class
WHERE relkind = 'p') AS parent_tables) SELE
On Tue, 21 May 2024 at 23:14, Laurenz Albe wrote:
> We still don't know the query.
hmm, it was posted on this thread:
https://postgr.es/m/CAGB0_6600w5C=hvhgfmwcqo9bcwcg+3s0pxxuoqv48nlqtp...@mail.gmail.com
David
On Tue, 2024-05-21 at 12:49 +0200, Sašo Gantar wrote:
> thanks for the info, but is there any solution, given that it's system tables?
We still don't know the query.
Yours,
Laurenz Albe
thanks for the info, but is there any solution, given that it's system
tables?
regards
On Tue, 21 May 2024 at 12:09, Laurenz Albe wrote:
> On Mon, 2024-05-20 at 13:08 +0200, Sašo Gantar wrote:
> [execution plan without query text or explanation]
>
> The time is lost here:
>
> -> WindowAgg (
On Mon, 20 May 2024 at 23:09, Sašo Gantar wrote:
> what helps is
> SET enable_nestloop = off;
> query takes less then 2seconds
> but it's probably not a good idea to change this flag
Looks like it's slow due to a bad selectivity estimate on the join
between pgn and pgc. This results in:
-> Nes
Thanks all for your answers ! Much appreciated.
Sent with Proton Mail secure email.
On Tuesday, 21 May 2024 at 11:02, Laurenz Albe wrote:
> On Mon, 2024-05-20 at 13:56 +0200, Erik Wienhold wrote:
>
> > On 2024-05-20 12:30 +0200, Laura Smith wrote:
> >
> > > Could someone kindly help me ou
On Mon, 2024-05-20 at 13:08 +0200, Sašo Gantar wrote:
[execution plan without query text or explanation]
The time is lost here:
-> WindowAgg (cost=310.01..358.34 rows=537 width=888) (actual
time=0.057..19.955 rows=473 loops=401)
Buffers: shared hit=1710825
Yours,
Laurenz Albe
On Mon, 2024-05-20 at 13:56 +0200, Erik Wienhold wrote:
> On 2024-05-20 12:30 +0200, Laura Smith wrote:
> > Could someone kindly help me out with the correct syntax ?
> >
> > My first thought was the below but that doesn't work:
> >
> > update foo set upper(bar_times)=upper(bar_times)+interval '1
23 matches
Mail list logo
