upgrade to "PostgreSQL 16.3 (Debian 16.3-1.pgdg120+1) on
x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit"
solved the problem
regards,
s
On Wed, 22 May 2024 at 06:04, Sašo Gantar wrote:
> ANALYZE pg_class; doesn't help
> also, query is from "Hasura", so I don't have much r
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
=?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
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
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
what helps is
SET enable_nestloop = off;
query takes less then 2seconds
but it's probably not a good idea to change this flag
On Wed, 15 May 2024 at 13:23, David Rowley wrote:
> On Wed, 15 May 2024 at 21:08, Sašo Gantar wrote:
> > this query takes more than 8 seconds,
> > if i remove "AND ((pg
>
>
> Aggregate (cost=512.53..512.54 rows=1 width=32) (actual
> time=8430.692..8430.724 rows=1 loops=1)
> Buffers: shared hit=2031540, temp read=954 written=956
> -> Subquery Scan on info (cost=510.85..512.52 rows=2 width=152)
> (actual time=8257.310..8430.532 rows=57 loops=1)
> Buff
On Wed, 15 May 2024 at 21:08, Sašo Gantar wrote:
> this query takes more than 8 seconds,
> if i remove "AND ((pgn.nspname='servicedesk'))" and test it, it takes <1s
Including the EXPLAIN rather than EXPLAIN (ANALYZE, BUFFERS) isn't
very useful as there's no way to tell if the planner's estimates
12 matches
Mail list logo
