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 1sMqvG-0052Ej-EW for pgsql-general@arkaria.postgresql.org; Thu, 27 Jun 2024 15:20:30 +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 1sMqvE-00ApV6-9D for pgsql-general@arkaria.postgresql.org; Thu, 27 Jun 2024 15:20:28 +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 1sMqvD-00ApUy-SO for pgsql-general@lists.postgresql.org; Thu, 27 Jun 2024 15:20:28 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sMqvA-003P69-WC for pgsql-general@lists.postgresql.org; Thu, 27 Jun 2024 15:20:26 +0000 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-424aa70fbc4so18468105e9.1 for ; Thu, 27 Jun 2024 08:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719501623; x=1720106423; darn=lists.postgresql.org; h=content-transfer-encoding:disposition-notification-to:subject:from :to:content-language:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=anZEZk+vy65FmgTOubF8QrYMvzKlbEA7WrHeLdtY14I=; b=jeF6gDAEx4y5sfKgM9KJ5ntuwqiu5oPG/yVrMDzkFmpMl7b4k7DXD6JME2ogQHDj2P YkwwfuG/00Yg0iXhvSzBjqQDHeDPV5LRO137iq97cTUVgMJW7QvihqHEgMJb+MdDmlG/ 2SBXRjR3ZbZoEgLwI5SJVjD8YtYArhcbtFKNFk5xlOpK0r4op7wIEjGVY+sciMwApLM5 00gXxidxlz3S512GqUvnDNfdjdtmouKjRsIOSr9nxs9JxawrPVU7zLmcdXTTPwlKdTZl PW4FBerHvZhlr8QgxYjxDxYmPJ55W035iznZRqDRhgZfw9mKNN0UZWQ84nJYTs/GisNJ lbYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719501623; x=1720106423; h=content-transfer-encoding:disposition-notification-to:subject:from :to:content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=anZEZk+vy65FmgTOubF8QrYMvzKlbEA7WrHeLdtY14I=; b=RHRrd/40wS+UV6uwygS4rO6u/GnI8XkkdZ6c7hfAEu1BFlXE3W1ZT80WK6S3P94qVM mZo40kNVN11nUze0n+ZyRmfqVhzJ57CQOjxELK30lzjYFTmj4AAmrOvHViRCHPADIPyV UoqZvL72d266YttRhm9Zv09on9UwjpZNYt3Ph2ol6fvhCmKLAP1SDB4BDNjAmsEIZat1 f35/ZvhXZ5vcggaS2IztVPWe3itWprWTN0rWuUkjz71o6BwHx9TV90g2pTCSszdME3/s iiF8WomkCFRosj++jLtAzEy0QzklpwB6zkP2kBc7pLWQfTF9nfPHQslw+vYKPu4ok2tQ W7zQ== X-Gm-Message-State: AOJu0YzKdLfhaoNsDUE9ru6WfVSar+b/PjZMpCdE7oniylIOiVFq5Vhn ki29YD81LtYabD5beZK8ndVTB1L1WdnYVnZs1itJpEXDdF8zmH2/SGQl X-Google-Smtp-Source: AGHT+IGKNgR3/aBM0ZI+0YMuvxmO1BcrRcavyg4Uu9KS2KeCve9yuwQVyV9bY4gMhaSPw1nhOjbEfQ== X-Received: by 2002:a5d:6681:0:b0:362:7c2e:e9f7 with SMTP id ffacd0b85a97d-366e94cbbe3mr8909116f8f.32.1719501623217; Thu, 27 Jun 2024 08:20:23 -0700 (PDT) Received: from [192.168.1.80] ([2.229.48.88]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3674357c1c8sm2202698f8f.9.2024.06.27.08.20.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jun 2024 08:20:22 -0700 (PDT) Message-ID: <451083be-83e8-413d-bc3a-ed7f3a6d99a9@gmail.com> Date: Thu, 27 Jun 2024 17:20:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: it To: pgsql-general@lists.postgresql.org From: "agharta82@gmail.com" Subject: A way to optimize sql about the last temporary-related row Disposition-Notification-To: "agharta82@gmail.com" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello everyone, Sorry to bother you but I have a query that is driving me crazy. I need to have the last valid record at a temporal level according to a specific parameter. First some data: Linux Rocky 8.10 environment, minimal installation (on VM KVM with Fedora 40). Postgresql 16.3, installed by official Postgresql guide. effective_cache_size = '1000 MB'; shared_buffers = '500 MB'; work_mem = '16MB'; The changes are deliberately minimal to be able to all to simulate the problem. Table script: CREATE TABLE test_table (  pk_id int NOT NULL,  integer_field_1 int ,  integer_field_2 int,  datetime_field_1 timestamp,  primary key (pk_id) ) -- insert 4M records insert into test_table(pk_id) select generate_series(1,4000000,1); -- now set some random data, distribuited between specific ranges (as in my production table) update test_table set datetime_field_1 = timestamp '2000-01-01 00:00:00' + random() * (timestamp '2024-05-31 23:59:59' - timestamp '2000-01-01 00:00:00'), integer_field_1 = floor(random() * (6-1+1) + 1)::int, integer_field_2 = floor(random() * (200000-1+1) + 1)::int; -- indexes CREATE INDEX idx_test_table_integer_field_1 ON test_table(integer_field_1); CREATE INDEX xtest_table_datetime_field_1 ON test_table(datetime_field_1 desc); CREATE INDEX idx_test_table_integer_field_2 ON test_table(integer_field_2); --vacuum vacuum full test_table; Now the query: explain (verbose, buffers, analyze) with last_table_ids as materialized(   select xx from (   select LAST_VALUE(pk_id) over (partition by integer_field_2 order by datetime_field_1 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) xx   from test_table   where integer_field_1 = 1   and datetime_field_1 <= CURRENT_TIMESTAMP   ) ww group by ww.xx ), last_row_per_ids as (   select tt.* from last_table_ids lt   inner join test_table tt on (tt.pk_id = lt.xx) ) select * /* or count(*) */ from last_row_per_ids; This query, on my PC, takes 46 seconds!!! I was expecting about 2-3 seconds (according with my other queries in this table) but it seems that the xtest_table_datetime_field_1 index is not being used. Do you think there is a way to optimize the query? Thanks so much for the support, Agharta