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.96) (envelope-from ) id 1vPOd6-000cvn-0Z for pgsql-general@arkaria.postgresql.org; Sat, 29 Nov 2025 17:21:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vPOc4-00F5o4-1E for pgsql-general@arkaria.postgresql.org; Sat, 29 Nov 2025 17:20:00 +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.96) (envelope-from ) id 1vP7PV-00DwJo-1L for pgsql-general@lists.postgresql.org; Fri, 28 Nov 2025 22:57:53 +0000 Received: from smtpout05.dka.mailcore.net ([185.138.56.205]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vP7PO-002433-10 for pgsql-general@postgresql.org; Fri, 28 Nov 2025 22:57:48 +0000 Received: from SMTP.DKA.mailcore.net (unknown [10.1.0.52]) by SMTPOUT01.DKA.mailcore.net (Postfix) with ESMTP id C04DDE00CA for ; Fri, 28 Nov 2025 23:57:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=online.ee; s=mailcore; t=1764370664; bh=2qgsnKi9V393zl147MtVrAqjQlwcOJMorx0komFuUEo=; h=Date:To:From:Subject:From; b=rnytztKJ6rHuRxldHiWASIAxyt0Sgp22d46WZL53MAC2hNlOnUOmt2XkZ1wFpJZ6N QS4Tf+NBlYwftkwrAYxUwSwnE7Iz5wdYcd6BeznR7eWMC347DrZK3K8KFTLaVSsNeY g+OIjddfbjCBmq1fxpGLHPl+WRW+SVC+s3e9g59ng6TbOWY1XnII2vZTvP9k1vruNK yJv+LaFXmmulDHa2/tELyW9lIBzRZtxtX/2gltHaY6Hf2BVHWjT1fiXabmI09792aA rFmIogUBZB6q+xoI4NfFp8iqWnA25WSW336PIr4GcJfExv+2tj3N1nJnZ3+Q4n48ZR GlJCuKmps+apQ== Received: from [192.168.1.38] (73-142-35-213.sta.estpak.ee [213.35.142.73]) by SMTP.DKA.mailcore.net (Postfix) with ESMTPSA id A5FBD400E7 for ; Fri, 28 Nov 2025 23:57:44 +0100 (CET) Content-Type: multipart/alternative; boundary="------------0XypM20kgPhLw0Ojd0BP5K8s" Message-ID: Date: Sat, 29 Nov 2025 00:57:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: et To: pgsql-general From: Andrus Subject: How to use index in simple select List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------0XypM20kgPhLw0Ojd0BP5K8s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi! Table has index on name column:         CREATE TABLE firma2.klient         (             kood character(12) primary key,              nimi character(100),            ...         );        CREATE INDEX IF NOT EXISTS klient_nimi_idx         ON firma2.klient USING btree         (nimi COLLATE pg_catalog."default" ASC NULLS LAST)         TABLESPACE pg_default; Database settings have default values:     enable_indexonlyscan       on     enable_indexscan           on     enable_indexonlyscan       on     enable_indexscan           on Query     SELECT * FROM firma2.klient WHERE nimi='John'; Runs slowly.     analyze firma2.klient;     explain analyze select * from firma2.klient where nimi='John' Shows that index is not used:     "Seq Scan on klient  (cost=0.00..2287976.20 rows=1 width=4002) (actual time=12769.987..12769.988 rows=0 loops=1)"     "  Filter: (nimi = 'John'::bpchar)"     "  Rows Removed by Filter: 849971"     "Planning Time: 4.751 ms"     "Execution Time: 12770.029 ms" How to force Postgres to use index? It probably worked long time but suddenly stopped working today. Re-started whole windows server but problem persists. Using PostgreSQL 17.5 on x86_64-windows, compiled by msvc-19.43.34808, 64-bit in Windows Server 2022 vers 21H2 Andrus. Posted also in https://stackoverflow.com/questions/79832965/how-to-use-index-in-simple-select --------------0XypM20kgPhLw0Ojd0BP5K8s Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi!

Table has index on name column:

        CREATE TABLE firma2.klient
        (
            kood character(12) primary key,
             nimi character(100),
           ...
        );
        
       CREATE INDEX IF NOT EXISTS klient_nimi_idx
        ON firma2.klient USING btree
        (nimi COLLATE pg_catalog."default" ASC NULLS LAST)
        TABLESPACE pg_default;

Database settings have default values:

    enable_indexonlyscan       on
    enable_indexscan           on
    enable_indexonlyscan       on
    enable_indexscan           on

Query 

    SELECT * FROM firma2.klient WHERE nimi='John';

Runs slowly.

    analyze firma2.klient; 
    explain analyze select * from firma2.klient where nimi='John'

Shows that index is not used:

    "Seq Scan on klient  (cost=0.00..2287976.20 rows=1 width=4002) (actual time=12769.987..12769.988 rows=0 loops=1)"
    "  Filter: (nimi = 'John'::bpchar)"
    "  Rows Removed by Filter: 849971"
    "Planning Time: 4.751 ms"
    "Execution Time: 12770.029 ms"

How to force Postgres to use index? It probably worked long time but suddenly stopped working today.
Re-started whole windows server but problem persists.

Using

PostgreSQL 17.5 on x86_64-windows, compiled by msvc-19.43.34808, 64-bit

in Windows Server 2022 vers 21H2

Andrus.


Posted also in

https://stackoverflow.com/questions/79832965/how-to-use-index-in-simple-select


--------------0XypM20kgPhLw0Ojd0BP5K8s--