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 1rGd5W-00GH1m-83 for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Dec 2023 10:49:06 +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 1rGd5U-005RUv-VR for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Dec 2023 10:49:04 +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 1rGd5U-005RUn-IA for pgsql-hackers@lists.postgresql.org; Fri, 22 Dec 2023 10:49:04 +0000 Received: from meesny.iki.fi ([2001:67c:2b0:1c1::201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rGd5R-00BeQS-Gn for pgsql-hackers@postgresql.org; Fri, 22 Dec 2023 10:49:03 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4SxPDR5p8DzyWK; Fri, 22 Dec 2023 12:48:55 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1703242137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g/+QyvITRDs77LYPw2V8z/i09plydBR9LH82GbyaH9Q=; b=JCHeYWF+c7j22512ZAh/iBPGSNQOiNGOd3y9YO0Z/NKT70DMinpiF+yIWEl54biJ+D3+nu 5uK8y/yfervm6ZVH7cc3ov8zH2tnCqU9Un29W0GlHXEcZo5uHR8TBYRcKTwG0oU/R2PlL1 P5uRyi0XT0l4jHEqhbivrB3iY4bUntQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1703242137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g/+QyvITRDs77LYPw2V8z/i09plydBR9LH82GbyaH9Q=; b=zLgnNQkF8+TOGl72q6x0coAYZXjR/DHrsDXRLQ9iAJ2SUBz/lJ2O3tAhgnCQI1S0TfFfDA a1ACp2sAIbUDJ0TPhnUco+uCyAkmlCumD1wFvBCluXfVaZG73BcYmdhS86c4g/SWws6vpu rLwa8g8AtGEQNXjnck6Sj0Vn9yJLm3o= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1703242137; a=rsa-sha256; cv=none; b=vUPbIMIOfCMqWs89M2cHmTQmZMoJqA1evBp256BV+LsAx+PfzP18daMpazC2v4koifNVGd LXUkRlIaP2tBQ/VKcgAZ73bbDwHNdDteXQw+vsezhg4ar6W/R7dzNuq3NAf10oiZkBONG8 b0M9iWgYr/U8MA1ew4h74BFsk6QO3Fk= Message-ID: Date: Fri, 22 Dec 2023 12:48:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Avoid computing ORDER BY junk columns unnecessarily Content-Language: en-US To: Xiaoran Wang Cc: pgsql-hackers , Andrew Kane , Matthias van de Meent References: <2ca5865b-4693-40e5-8f78-f3b45d5378fb@iki.fi> From: Heikki Linnakangas In-Reply-To: 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 On 22/12/2023 11:05, Xiaoran Wang wrote: > I haven't dug into your patch yet, but for this problem, I have another > idea. > ------- > explain verbose >   select foo from mytable order by sha256(bar::bytea); > >                                             QUERY PLAN > > ------------------------------------------------------------------------------------------------ >   Index Scan using mytable_sha256_idx on public.mytable > (cost=0.29..737.28 rows=10000 width=64) >     Output: foo, sha256((bar)::bytea) > (2 rows) > > The index is used to satisfy the ORDER BY, but the expensive ORDER BY > expression is still computed for every row, just to be thrown away by > the junk filter. > ------ > How about adding the orderby column value  in 'xs_heaptid' with the > 'xs_heaptid' > together? So that we can use that value directly instead of computing it > when using > an index scan to fetch the ordered data. Hmm, so return the computed column from the index instead of recomputing it? Yeah, that makes sense too and would help in this example. It won't help in all cases though, the index might not store the original value in the first place. -- Heikki Linnakangas Neon (https://neon.tech)