Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WJ6E5-0007J5-Cn for pgsql-performance@arkaria.postgresql.org; Thu, 27 Feb 2014 19:02:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WJ6E4-0000dn-PE for pgsql-performance@arkaria.postgresql.org; Thu, 27 Feb 2014 19:02:32 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WJ6E3-0000dg-Jm for pgsql-performance@postgresql.org; Thu, 27 Feb 2014 19:02:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WJ6E1-0002ue-Aj for pgsql-performance@postgresql.org; Thu, 27 Feb 2014 19:02:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s1RJ2RSB004828; Thu, 27 Feb 2014 14:02:27 -0500 From: Tom Lane To: Stephen Frost cc: Tom Coogan , pgsql-performance@postgresql.org Subject: Re: Inefficient filter order in query plan In-reply-to: <20140227182411.GR2921@tamriel.snowman.net> References: <1633.1393520657@sss.pgh.pa.us> <20140227182411.GR2921@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Thu, 27 Feb 2014 13:24:11 -0500" Date: Thu, 27 Feb 2014 14:02:27 -0500 Message-ID: <4827.1393527747@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) 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 Stephen Frost writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> You could try increasing the cost attributed to the texticlike() function >> if you don't like the results you're getting here. > Perhaps we should be attributing some additional cost to operations > which (are likely to) require de-TOAST'ing a bunch of values? It's not > obvious from the original email, but it's at least my suspicion that the > difference is amplified due to de-TOAST'ing of the values in that text > column, in addition to the straight-up function execution time > differences. Could be. We've discussed adding some charge for touching likely-to-be-toasted columns in the past, but nobody's done anything about it. Note that I'd rather see that implemented as a nonzero cost for Vars than as a charge for functions per se. > Costing integer (or anything that doesn't require pointer maniuplations) > operations as cheaper than text-based operations also makes sense to me, > even though of course there's more things happening when we do these > comparisons than the simple CPU-level act of doing the cmp. Right. We've bumped up the cost numbers for some extremely expensive functions, but I would like to have some actual data rather than just seat of the pants guesses before we go fooling with the standard CPU cost estimates for things at the level of regex matches. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance