X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 1F763D1C518; Mon, 4 Aug 2003 20:33:33 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 45342-06; Mon, 4 Aug 2003 17:32:17 -0300 (ADT) Received: from joeconway.com (66-146-172-86.skyriver.net [66.146.172.86]) by svr1.postgresql.org (Postfix) with ESMTP id 747DCD1C4ED; Mon, 4 Aug 2003 17:33:21 -0300 (ADT) Received: from [206.19.64.3] (account jconway HELO joeconway.com) by joeconway.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 22796; Mon, 04 Aug 2003 12:54:47 -0700 Message-ID: <3F2EC244.9040107@joeconway.com> Date: Mon, 04 Aug 2003 13:29:56 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Cain Cc: Tom Lane , PgSQL Performance ML , pgsql-sql@postgresql.org Subject: Re: [SQL] EXTERNAL storage and substring on long strings References: <1059679600.1429.41.camel@localhost.localdomain> <3F297CBA.1080703@joeconway.com> <1059686498.7505.558.camel@haggis> <1060010735.1433.26.camel@localhost.localdomain> <3574.1060012423@sss.pgh.pa.us> <1060014341.1434.53.camel@localhost.localdomain> In-Reply-To: <1060014341.1434.53.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/43 X-Sequence-Number: 2860 Scott Cain wrote: > On Mon, 2003-08-04 at 11:53, Tom Lane wrote: >>I find it really, really hard to believe that a crude reimplementation >>in plpgsql of the TOAST concept could beat the built-in implementation >>at all, let alone beat it by two orders of magnitude. >> >>Either there's something unrealistic about your testing of the >>dna_string function, or your original tests are not causing TOAST to be >>invoked in the expected way, or there's a bug we need to fix. I'd >>really like to see some profiling of the poor-performing >>external-storage case, so we can figure out what's going on. > > I was really hoping for a "Good job and glad to hear it" from you :-) > > I don't think there is anything unrealistic about my function or its > testing, as it is very much along the lines of the types of things we do > now. I will really try to do some profiling this week to help figure > out what is going on. Is there a sample table schema and dataset available (external-storage case) that we can play with? Joe