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 ) id 1gn4ti-0000cs-A1 for pgsql-admin@arkaria.postgresql.org; Fri, 25 Jan 2019 17:04:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gn4th-0005rb-2G for pgsql-admin@arkaria.postgresql.org; Fri, 25 Jan 2019 17:04:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gn4tg-0005rT-Lh for pgsql-admin@lists.postgresql.org; Fri, 25 Jan 2019 17:04:04 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gn4te-0006sL-1b for pgsql-admin@postgresql.org; Fri, 25 Jan 2019 17:04:03 +0000 Received: by mail-wm1-x330.google.com with SMTP id g67so7300126wmd.2 for ; Fri, 25 Jan 2019 09:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=B1mB/itDiTGLqU0rMeJQ9Nozc5KN3TMrmFH3WGS/o6w=; b=uPGSpEWoC8+75VQJp3zLlc+QH6BE4TsDZH48zAVTUefbMGWR+MpkDuL7LjxAlIU3n5 s8Z4/W+6fltZm/QsmSe6pAaT7N6gYActWWY/XWxzU8rKonO31ydqlGCwKsDTkO4nqfN0 pv6piiQ9bvH67CbNB7y5nO5ZkyazZ0BXe0mbRfc1AxlMMKJvaS2TwN/RPW3bUGUL+i9C QmW0OeBiFjw3WCg+OE0bTOtxgCr06OaqjcrCqUOuzw1OBcHmW7l1MoOEm/ohewbsvDmc q2xfV0gEsRsie0+/o1JacFmqCFlIo3niSzEEJcHuFhHML5kyiHGd5RRQaSbttXjpPFs2 iebg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=B1mB/itDiTGLqU0rMeJQ9Nozc5KN3TMrmFH3WGS/o6w=; b=jC0jAWWWctVR7nFXlYbB8FHgBJmXd94JEX8tjU/S1UJARyLBs2olcYGi9dyyCwkL9u 0EmvzeYU/4xBHUuIV3GM9tAfPl3OP2yzkP3tr1tmR93mhmAvEGIWy2SmLIyboBQmtuEh Vova2ywJlFvma2DN+Y/KLfzOO9CL8W3U8LJPmlagasDUvyb/HRqDm6HkFN+hsOoEPfnM NTf3A+mdvmF7862ySgX4k1MsgmgEfsKBLEv9hNEP0H5Kzus+rX2EDZLhkzM52n/3wFOW kjmVEMeeBUnBh4VynZogAP8weX8crQotGDeSaXolLghgJ8BgMpPIz7cp5qO5jcxZbfON 7uvA== X-Gm-Message-State: AJcUukcFm5yOjy5azOhhI94tmfjXOZUOVEYOQSVdOTYck8LYj4bvLTTp 3x9H3xL5+arabA9oERU7IzNUBK7X X-Google-Smtp-Source: ALg8bN5TuwfmXJ8hVSdeUgTWt2iTNe07pdQmfbOsE8uHk8zmpHPTNGnRGXB8dt8y86mvTvuX4c5o4A== X-Received: by 2002:a7b:c399:: with SMTP id s25mr7808247wmj.90.1548435837431; Fri, 25 Jan 2019 09:03:57 -0800 (PST) Received: from [172.30.1.193] ([5.90.84.155]) by smtp.googlemail.com with ESMTPSA id e9sm89009525wro.16.2019.01.25.09.03.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jan 2019 09:03:56 -0800 (PST) To: pgsql-admin@postgresql.org From: Alessandro Manzoni Subject: Strange performance problem Message-ID: <0f9efbe6-9adc-2732-1257-b4fc0367b0f3@gmail.com> Date: Fri, 25 Jan 2019 18:02:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Antivirus: Avast (VPS 190125-2, 25/01/2019), Outbound message X-Antivirus-Status: Clean List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I have a table, let's say 'tableone' with some thousands rows, on that table I created an index on a single field, let's say 'fieldone' of type character(3). I have also a view, let's say 'viewone' that selects rows from tableone for a certain value of fieldone (created with the query "select * from tableone where fieldone = 'one'" ), so if I try: select * from tableone where fieldone = 'one' or select * from viewone obviously I get the same result and the same performance: a few ms, Then I have a complex query that has two complete different performances, in these two cases: case a) with getfieldone as (select * from tableone where fieldone = 'one') select * from getfieldone inner join tabletwo on ... [and other joins] case b) select * from viewone inner join tabletwo on ... [and other joins, the same as case a)] I expected the same performance, but case a) lasts a few hundreds ms, while case b) lasts more than 12 seconds. In both cases I execute as explain I see that selecting the table the proper index was involved, The database is a test one, so I'm the sole user, and I act as the owner role. I don't understand this behavior. What should I do? Any advise?