Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cerPC-0003Pi-JU for pgsql-performance@arkaria.postgresql.org; Fri, 17 Feb 2017 22:53:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cerPC-00045S-6K for pgsql-performance@arkaria.postgresql.org; Fri, 17 Feb 2017 22:53:34 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cerNV-0001Tq-UG for pgsql-performance@postgresql.org; Fri, 17 Feb 2017 22:51:50 +0000 Received: from mail-qk0-x22c.google.com ([2607:f8b0:400d:c09::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cerNT-0000DI-Da for pgsql-performance@postgresql.org; Fri, 17 Feb 2017 22:51:48 +0000 Received: by mail-qk0-x22c.google.com with SMTP id s186so57371864qkb.1 for ; Fri, 17 Feb 2017 14:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=VaEN2dcO0Gfsz+35wmzurDdEF267INMeK0esLZ6RIcQ=; b=QpQ62T/frCFYN4QoqTgs2U2pVeDUe9jXj0HDDhyo1aEDRvXi5xNbp1V15vL692tk/0 9ul90qzpmPjFtbccLJzWnU3O/xLYFGpctORjb7QaSNFPyAuY/1GLWqUZcoAkZjlulP7B k/NPhw41OISVqy4NImqWgnhzBE124ZVWdS/mGtrXRqs6R4pUNsqRAFyQQZiB1EGnY8DQ sl7L1WW6OJ54LRHb1bFJjD+AKwGbXmLkpU+2Aws2qEwOjqBCsPyKzSA1MK1YlO1DxUk7 XPG+pNCuvyDx31RCwG9FNqB6qwURYvb8mQaNnP0VfR0vi/fXI6q/CyZ0IRPYO983UEG9 OPOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=VaEN2dcO0Gfsz+35wmzurDdEF267INMeK0esLZ6RIcQ=; b=LvbyG6Gbd+Jw8ZRxPjlpUYzUalZe/+jLSFTZBvCxD0/mzK9ugnZL8RQ/gXELhZ9prj I+o8ZDysXB6P6/0kPwETwrEDOtuJ6U0Vog5DFqwjHqL1C91CzjmxQJFB/hH2SlApaHyW dPYFM/s3b4xraPivlv7nKek9aQoOax8ASje0+u3/Zzli7Aet8nPH3YNmppDKbN0B0ggt V04/WU504a1PHzCdH26xZfcrBU+b8tQTCQZMgZlqK42/OQJdPm+ccvpZfTbHBnt1jluz 6J0w+vBCQE/1x5yyOqVrxtXvZ9fRenDkF6NugeoiTnq5zEcHVS7aBoy8+i7nh7Hipf2L yTEQ== X-Gm-Message-State: AMke39mUKwlnS2TTx0wI14zuZGBOFsPx1Bk3cZzrmUjFTI9MOaR74VgiaWkBKIhc/X2SGZiG X-Received: by 10.55.116.70 with SMTP id p67mr9484650qkc.216.1487371906063; Fri, 17 Feb 2017 14:51:46 -0800 (PST) Received: from alvin.alvh.no-ip.org ([179.57.115.10]) by smtp.gmail.com with ESMTPSA id y185sm7380719qkc.28.2017.02.17.14.51.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 14:51:45 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 863A6822; Fri, 17 Feb 2017 19:51:43 -0300 (CLST) Date: Fri, 17 Feb 2017 19:51:43 -0300 From: Alvaro Herrera To: Hustler DBA Cc: pgsql-performance@postgresql.org Subject: Re: Number of characters in column preventing index usage Message-ID: <20170217225143.gvcu4d5vqw23ig64@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170206-195-7adf12 (1.7.2) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hustler DBA wrote: > I am seeing this strange behavior, I don't know if this is by design by > Postgres. > > I have an index on a column which is defined as "character varying(255)". > When the value I am searching for is of a certain length, the optimizer > uses the index but when the value is long, the optimizer doesn't use the > index but does a seq scan on the table. Is this by design? How can I make > the optimizer use the index no matter what the size/length of the value > being searched for? As I recall, selectivity for strings is estimated based on the length of the string. Since your sample string looks suspiciously like an UUID, perhaps you'd be better served by using an UUID column for it, which may give better results. This would prevent you from using the shortened version for searches (which I suppose you can do with LIKE using the varchar type), but you could replace it with something like this: select * from tab where ID between '01625cfa-2bf8-45cf-0000-000000000000' and '01625cfa-2bf8-45cf-ffff-ffffffffffff'; Storage (both the table and indexes) is going to be more efficient this way too. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance