Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1i0r7I-00085a-Ng
	for pgsql-performance@arkaria.postgresql.org; Thu, 22 Aug 2019 17:43:20 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1i0r7H-0002LD-1l
	for pgsql-performance@arkaria.postgresql.org; Thu, 22 Aug 2019 17:43:19 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <legrand_legrand@hotmail.com>)
	id 1i0r7G-0002G5-Me
	for pgsql-performance@lists.postgresql.org; Thu, 22 Aug 2019 17:43:18 +0000
Received: from n3.nabble.com ([162.255.23.22])
	by magus.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <legrand_legrand@hotmail.com>)
	id 1i0r7C-0005gB-8z
	for pgsql-performance@postgresql.org; Thu, 22 Aug 2019 17:43:17 +0000
Received: from n3.nabble.com (localhost [127.0.0.1])
	by n3.nabble.com (Postfix) with ESMTP id 07CB8168BD4F6
	for <pgsql-performance@postgresql.org>; Thu, 22 Aug 2019 10:43:12 -0700 (MST)
Date: Thu, 22 Aug 2019 10:43:10 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1566495790294-0.post@n3.nabble.com>
In-Reply-To: 
 <CAB14va9Mt4QVV_aR3rXxvaVyGNjB-5TpK6FSHAmdfMMu+PL-GA@mail.gmail.com>
References: 
 <CAB14va-2iukzjQyA6rBQfeQuMMbd8Z+f22fvM3H9k+PxKa-_sw@mail.gmail.com>
 <9736f758-d702-ee9a-2988-53762c73c3e3@siscobra.com.br>
 <CAB14va_b+mCmZrp1R_FHgcp54HQ+Vq9e=MMg22DYLvWqb0XQTQ@mail.gmail.com>
 <827127b6-c034-b53b-5c2d-aa04743298d2@siscobra.com.br>
 <CAB14va_8pxe20vcroB9nyhmWSw=jBqAZxd6G54uE-xTpKR1yEg@mail.gmail.com>
 <de19053e-5d69-6bd9-0d48-62475283e8a4@siscobra.com.br>
 <CAB14va8TnWBkLYUAt6YhfwnOU+RMOvQmJzeJMsnadt2G58aitg@mail.gmail.com>
 <CAB14va9Mt4QVV_aR3rXxvaVyGNjB-5TpK6FSHAmdfMMu+PL-GA@mail.gmail.com>
Subject: Re: Erratically behaving query needs optimization
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Id: <pgsql-performance.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-performance@lists.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-performance>
Precedence: bulk

Hello,

1/ access scheduler_task_executions 
	by index with device_id = 97
seems ok

2/ 
I don't understand why 
joining
scheduler_task_executions.id=scheduler_operation_executions.task_execution_id
is done using a parallel hash join 
when a nested loop would be better (regarding the number of rows involved)

maybe because index on scheduler_operation_executions.task_execution_id

    "index_task_execution_id_desc" btree (task_execution_id DESC NULLS LAST)

is not usable or bloated or because of DESC NULLS LAST ?


3/ join with results.operation_execution_id
	by index
seems OK

Regards
PAscal



--
Sent from: https://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html