Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jRa9y-0002cN-OG for pgsql-performance@arkaria.postgresql.org; Thu, 23 Apr 2020 11:36:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jRa9x-0002if-Kg for pgsql-performance@arkaria.postgresql.org; Thu, 23 Apr 2020 11:36:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jRa9x-0002iY-Ad for pgsql-performance@lists.postgresql.org; Thu, 23 Apr 2020 11:36:49 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jRa9u-0001mO-W1 for pgsql-performance@lists.postgresql.org; Thu, 23 Apr 2020 11:36:48 +0000 Received: by mail-wr1-x443.google.com with SMTP id j1so6452826wrt.1 for ; Thu, 23 Apr 2020 04:36:46 -0700 (PDT) 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=Q/PQldmhsj/kQBPGeRcqpeTM/kLgvisgkZFfR0/rNc0=; b=QRY87VSV/tgviYXqGQ9GYeUquT90YDSUhafVmASyibrabBkRgqg/psgWUHwlzSY/1J gEk3X0QtoPyOxC5mhHI0fx9kAW0dD6w6QkvxiunpebwaTsbTLOfus6/tPAVl1I6DCxAl OiqJ3IW+1qGfqCNC14LYQZzgzYr6Kj5WFPJvSGW3lhaX84kNxhuJi2HXDysldadw/rK0 RvxKqev+ap/GodOMbm6mZ1jvy6kIzOnhfP3GQhQXJzGBA8WSMAyVdE7LOEeBzWCQetSI 8UzBSm5XdhMOIPZOtZ94gtve8S8GhAbnnvHPXB6wvdae5n0zhURtEohazLtLV6ucrYP3 3+yg== 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=Q/PQldmhsj/kQBPGeRcqpeTM/kLgvisgkZFfR0/rNc0=; b=TNB0N24LiqRgK6Qy5Q9ZMmkO+PY4lp9myxvRp0UqWwIXoO8XCTslxNwfheG/SKgISL hEJrIaCunmctXJRmNQlZ5uB3Liddt5X038q1Tg1j7wbX/s98CvAILAn8BkG+7IvZV5m2 uRkFsS/LYeW6VXxqBf+w6NNfKUMqlnc6i8oYxSP4OuBnAjenOVVGAl+s/Yx0awscnaNQ gVa8psHutmHRaQKJ8jUvopmoqFg8f8wISGv+Z/l9quAKdN0YGL9khV8FYbAxQ24op+WB nGvnqTI3ljC3GSV8j6K78HtxM+OLyBHlfYGsZ0J3AUy6+bWdoDXUQDIjSXsnXdZVysw/ Oe3g== X-Gm-Message-State: AGi0PuZPEYaN/D8C+eFDlVQFpoCzhvuar/QMrsO7hgqsWLpI5KZYChD3 skRbD8/WtXO8uEedL3QbVA3Kl+pq7Ek= X-Google-Smtp-Source: APiQypJgvqMHmm3TNhDEqcF/AzRBIe13IYyrb74yybcGonea81nTboauD1EtFa9IuJK7oDt2aoWpeQ== X-Received: by 2002:adf:a3d5:: with SMTP id m21mr4639183wrb.54.1587641805003; Thu, 23 Apr 2020 04:36:45 -0700 (PDT) Received: from [192.168.2.100] (32.red-80-39-211.dynamicip.rima-tde.net. [80.39.211.32]) by smtp.googlemail.com with ESMTPSA id i19sm3670257wrb.16.2020.04.23.04.36.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Apr 2020 04:36:44 -0700 (PDT) To: pgsql-performance@lists.postgresql.org From: Arcadio Ortega Reinoso Subject: PostgreSQL does not choose my indexes well Message-ID: <35dc90d6-e0c2-13b8-3184-e3db5d854a78@gmail.com> Date: Thu, 23 Apr 2020 13:36:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, I don't understand why postgresql doesn't use clearly the most optimal index for a query in PLAN. Can you help me? create table public.tabla (     cod_tabla bigint not null,     tabla varchar(31) not null,     constraint pk_tabla primary key (cod_tabla) ); create table public.entidad (     cod_entidad bigint not null,     cod_tabla bigint not null,     cod_entidad_tabla bigint not null,     constraint pk_entidad primary key (cod_entidad),     constraint fk_tabla_entidad foreign key (cod_tabla)         references public.tabla (cod_tabla) match simple         on update cascade         on delete cascade ); CREATE INDEX idx_tabla_entidad     ON public.entidad USING btree     (cod_tabla ASC NULLS LAST); CREATE INDEX idx_entidad_tabla_4     ON public.entidad USING btree     (cod_entidad_tabla ASC NULLS LAST)     INCLUDE(cod_entidad, cod_tabla, cod_entidad_tabla)     WHERE cod_tabla::bigint = 4; SELECT count(*) from entidad; 34.413.354 SELECT count(*) from entidad where cod_tabla = 4; 1.409.985 explain (analyze, buffers, format text) select * from entidad where cod_tabla = 4 Index Scan using idx_tabla_entidad on entidad (cost=0.56..51121.41 rows=1405216 width=20) (actual time=0.037..242.609 rows=1409985 loops=1)   Index Cond: ((cod_tabla)::bigint = 4)   Buffers: shared hit=12839 Planning Time: 0.158 ms Execution Time: 311.828 ms Why postgresql doesnt use the index idx_entidad_tabla_4????? Thanks in advance