Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 12BD2476537; Wed, 27 Nov 2002 11:59:16 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 0AD5E476626; Wed, 27 Nov 2002 11:56:31 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.6/8.12.6) with ESMTP id gARGuYsX018355; Wed, 27 Nov 2002 11:56:34 -0500 (EST) To: Achilleus Mantzios Cc: pgsql-general@postgresql.org, pgsql-sql@postgresql.org Subject: Re: FreeBSD, Linux: select, select count(*) performance In-reply-to: References: Comments: In-reply-to Achilleus Mantzios message dated "Wed, 27 Nov 2002 18:35:20 +0200" Date: Wed, 27 Nov 2002 11:56:34 -0500 Message-ID: <18354.1038416194@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/1270 X-Sequence-Number: 33690 Achilleus Mantzios writes: > On Wed, 27 Nov 2002, Tom Lane wrote: >> You didn't say what was *in* the table, exactly ... but I'm betting >> there are a lot of toasted columns, and that the extra runtime >> represents the time to fetch (and perhaps decompress) the TOAST entries. > 278 columns of various types. > namely, > [snip] Hmm, no particularly wide columns there --- but 278 columns is a lot. I think the extra time might just be the time involved in fetching all those column values out of the table row? If you're interested in pursuing it, I'd suggest rebuilding the backend with profiling enabled so you can see exactly where the time goes. regards, tom lane