Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s92Li-00GvL3-VV for pgsql-general@arkaria.postgresql.org; Mon, 20 May 2024 12:42:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s92Li-001kGs-UB for pgsql-general@arkaria.postgresql.org; Mon, 20 May 2024 12:42:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s90tH-000rFZ-Hk for pgsql-general@lists.postgresql.org; Mon, 20 May 2024 11:09:15 +0000 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s90tE-001BG3-F1 for pgsql-general@lists.postgresql.org; Mon, 20 May 2024 11:09:14 +0000 Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-792bf1a4f75so260665385a.2 for ; Mon, 20 May 2024 04:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716203352; x=1716808152; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vA1Lbj4Y1apgcJJK47ZLrTZ2ODYV4/a9mFkA4ZSc+sM=; b=jdy/idnzIUQkqA8AXfTJ6xDObWVnpKSiG8Fb7hntjyZz0SSEj+99Y1U8EXQxmDU2z9 7p6TyUwimh2/MiVyNKMZZSH3FuvTgs2nW1bHtduBMPOhl3CEHOfL7yzRf6U5NWzHZq8g ZxxkznJHf4I4A4tFcsqNrjTNl+CFBdYbkvL+ju6qjP7ZsbPyuWXR5yOBBee4LCcgSbeb LOrgATqklD/at6ssAYHb8M0gis1pwiBOBtO+nfWqwNtMdrrbZEns2PDB0FDQAUXX0VNx T6kqwHKDQhEFv5HhC+Ph8pAsLGX/XKHOBzAk4Wr0z86kk9ZNEe6CIx/zNKOOeoXnY8iB sHKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716203352; x=1716808152; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vA1Lbj4Y1apgcJJK47ZLrTZ2ODYV4/a9mFkA4ZSc+sM=; b=VdgDUR6uYiT0vMOBp5P1V5aehowz8QSKXpIJVWBHl6sGJP/8ba+6o0qnM0hMBZBU16 XgF7NyI/yaizfqmeCK2EDIFJGxUboacCPJDNC2JeTryfqI78vebMT6JRgfKkQ+x9opjV +t7X37dIhJvtIVC7GqEraTvDfKUwGQihbzhhT8jFMCqdxs6ganMbz7eIJi1FY7SIglGA PT0h/w8iS/zf0kQUMjUXgx7pfryuRNkDRnpV/baSl3oM5AewAVzcxqnbbWS5If0/ojWP +IVLsECuy6ww6ABoqRfG5Zrw/cG6e8v4aAWUBfqw0qdGAmbzb3+bVFwVRiXkdqZjnLwZ o+Nw== X-Gm-Message-State: AOJu0YwRx5jdsWejfOCHJLV4SOLsuN8iIpi/Odsy/k37qErv6hpbodRx ayRFtKGGJc0crck5PcU5RT0wcXLfTKyFdzIAT1odIPVeJ4R5WF9Tkz0rGCrH3vSc0kmSJN9/8wh 3htrVR88crokGCJDWVIezi0l2YAs= X-Google-Smtp-Source: AGHT+IHUKYBMOUHxEL4LauvfLYtdIifCvu3Rs0Ch23H83CJvoEVJ6GX1CGh20MeknM8FfST54qnjHs/uALr1JjJf5U4= X-Received: by 2002:a05:620a:3624:b0:793:c6:409b with SMTP id af79cd13be357-79300c646e1mr1326777685a.47.1716203351716; Mon, 20 May 2024 04:09:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?U2HFoW8gR2FudGFy?= Date: Mon, 20 May 2024 13:09:00 +0200 Message-ID: Subject: Re: problem with query To: David Rowley Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000243be40618e0bb38" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000243be40618e0bb38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable what helps is SET enable_nestloop =3D 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=C5=A1o Gantar wrote: > > this query takes more than 8 seconds, > > if i remove "AND ((pgn.nspname=3D'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 were > accurate or not. Also with EXPLAIN only, we don't know where the time > was spent in the query. > > Running the EXPLAIN with "SET track_io_timing =3D 1;" would be even more > useful. > > David > --000000000000243be40618e0bb38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
what helps is =C2=A0 =C2=A0
SET enable_nestloop =3D 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 &l= t;dgrowleyml@gmail.com> wrot= e:
On Wed, 15 Ma= y 2024 at 21:08, Sa=C5=A1o Gantar <sasog23@gmail.com> wrote:
> this query takes more than 8 seconds,
> if i remove "AND ((pgn.nspname=3D'servicedesk'))" an= d 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 we= re
accurate or not. Also with EXPLAIN only, we don't know where the time was spent in the query.

Running the EXPLAIN with "SET track_io_timing =3D 1;" would be ev= en more useful.

David
--000000000000243be40618e0bb38--