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.94.2) (envelope-from ) id 1qUdjR-00DcIR-2u for pgsql-sql@arkaria.postgresql.org; Sat, 12 Aug 2023 01:47:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qUdjP-00DYCA-Kd for pgsql-sql@arkaria.postgresql.org; Sat, 12 Aug 2023 01:47:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qUdjO-00DXwZ-Rf for pgsql-sql@lists.postgresql.org; Sat, 12 Aug 2023 01:47:55 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qUdjM-001tTI-2z for pgsql-sql@lists.postgresql.org; Sat, 12 Aug 2023 01:47:54 +0000 Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-26830595676so1732987a91.2 for ; Fri, 11 Aug 2023 18:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heimdalldata.com; s=google; t=1691804871; x=1692409671; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2UZG/80+wN/bPque+oIVeU3qRvv99oG92g2rU6qmn+4=; b=tAttYgLWqCsK+aVOPvqDBYKhU7/wQR/OcPXJM4mfL5MN6RdVAzjJ3Uxzr87eGZAD7J FYJZ2WPvmdJiNPftLtnoBbw+bulL7yegPgXVvvCCDg0bYb82rbCWWsK/WmhvRghQk/BE G41G0PBVg+lr1YvHuZN5IcT5fNwnghREE0RSs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691804871; x=1692409671; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2UZG/80+wN/bPque+oIVeU3qRvv99oG92g2rU6qmn+4=; b=VlPYLBTWd2fgJJMZ1rpqpRTX/KOG/2Ph4S2T0nNgvcipHWqkhoMJx2wYwFsz7WqKox jtHJr0zGG0xiFqX8wDHlyOtXzpq6e0RAKjAqaCTWBxBnc5kETD2NVhZ8FOfwAZRlKPGF WJUQUInM+fINY32/aHd951zkEPYr7u08BFG/nYDeudKvquQPKnHWznbf9bVvQB4EyTrS 2WZYFn4mnC3MNKg7J/7jok0s79aaKSbqCsRvobwaIEUGhWX5tZC4TIm10pv6Pj6MhqK3 oFb7IXhBB+ChWlZoLI0ZtI23zCcKJRnTueuKs3vUvVaPb8bF7GhBZk5e97JP833TIw/E 9v+w== X-Gm-Message-State: AOJu0YzqqFug6sQKN2yT7lCbV+QhRub1y/epsDZxLZTLYTNPGYfSIwmx KcEv7GxvECjRttfve9+vJafnFS+Hhnm0fBS4bce8lelEsD72kVJu X-Google-Smtp-Source: AGHT+IFlkIhd+zJn2cksp+DH72YRzPQHtt56snF3yD2SihJj3O4k+tL6GNl0TjTeWdm5Cu6fPNU6Ch5vXZjQOzxRnQ8= X-Received: by 2002:a17:90a:cf16:b0:262:f99b:a530 with SMTP id h22-20020a17090acf1600b00262f99ba530mr3050738pju.34.1691804870931; Fri, 11 Aug 2023 18:47:50 -0700 (PDT) MIME-Version: 1.0 References: <26113e89-fc44-e0bd-7c4a-b899d5bc591e@useunix.net> In-Reply-To: <26113e89-fc44-e0bd-7c4a-b899d5bc591e@useunix.net> From: Erik Brandsberg Date: Fri, 11 Aug 2023 21:47:38 -0400 Message-ID: Subject: Re: index not being used To: lists-pgsql@useunix.net Cc: pgsql-sql Content-Type: multipart/alternative; boundary="0000000000005c8e740602b0041c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005c8e740602b0041c Content-Type: text/plain; charset="UTF-8" If there are only a few values of sat, then a sequential scan may in fact be the optimal path. On Fri, Aug 11, 2023, 9:16 PM wrote: > I'm running an older PostgreSQL 9.1 database. I know it's old... an > upgrade is planned. > > I have a table with the following columns. > > Column | Type | Modifiers | Storage | Description > --------+---------+-----------+----------+------------- > sat | text | not null | extended | > ts | bigint | not null | plain | > apid | integer | not null | plain | > bin | integer | not null | plain | > value | bigint | not null | plain | > > A unique index on (sat, ts, apid, bin). > > There are only a handful of unique sat values but there are about 20 > million rows in the table as there are many apid values per unit time. > > This query is fast and uses the index: > > select max(ts) > from table > where sat = 'XX'; > > While this query results in sequential scans and long execution times: > > select sat, max(ts) > from histograms > where sat in ('A1', 'A2', 'S1', 'S2') > group by 1; > > Is there any way to formulate this query to make it faster without > adding an additional index? > > Thank you in advance, > Wayne > > > --0000000000005c8e740602b0041c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If there are only a few values of sat, then a sequential = scan may in fact be the optimal path.

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 11, 2023, 9:16 PM <lists-pgsql@useunix.net> wro= te:
I'm running an older Postgr= eSQL 9.1 database. I know it's old... an
upgrade is planned.

I have a table with the following columns.

=C2=A0 Column |=C2=A0 Type=C2=A0 =C2=A0| Modifiers | Storage=C2=A0 | Descri= ption
--------+---------+-----------+----------+-------------
=C2=A0 sat=C2=A0 =C2=A0 | text=C2=A0 =C2=A0 | not null=C2=A0 | extended | =C2=A0 ts=C2=A0 =C2=A0 =C2=A0| bigint=C2=A0 | not null=C2=A0 | plain=C2=A0 = =C2=A0 |
=C2=A0 apid=C2=A0 =C2=A0| integer | not null=C2=A0 | plain=C2=A0 =C2=A0 | =C2=A0 bin=C2=A0 =C2=A0 | integer | not null=C2=A0 | plain=C2=A0 =C2=A0 | =C2=A0 value=C2=A0 | bigint=C2=A0 | not null=C2=A0 | plain=C2=A0 =C2=A0 |
A unique index on (sat, ts, apid, bin).

There are only a handful of unique sat values but there are about 20
million rows in the table as there are many apid values per unit time.

This query is fast and uses the index:

select max(ts)
from table
where sat =3D 'XX';

While this query results in sequential scans and long execution times:

select sat, max(ts)
from histograms
where sat in ('A1', 'A2', 'S1', 'S2')
group by 1;

Is there any way to formulate this query to make it faster without
adding an additional index?

Thank you in advance,
Wayne


--0000000000005c8e740602b0041c--