X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id E89BD9FB1F0 for ; Tue, 2 May 2006 17:13:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 19982-02 for ; Tue, 2 May 2006 17:13:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 3EE329FB1D3 for ; Tue, 2 May 2006 17:13:37 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id C804A5643D; Tue, 2 May 2006 15:13:35 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 2 May 2006 15:13:35 -0500 Date: Tue, 2 May 2006 15:13:35 -0500 From: "Jim C. Nasby" To: K C Lau Cc: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Why so slow? Message-ID: <20060502201334.GA97354@pervasive.com> References: <20060428145842.GI97354@pervasive.com> <20060428190005.GA15689@wolff.to> <6.2.1.2.0.20060429084119.05290438@localhost> <19397.1146278368@sss.pgh.pa.us> <6.2.1.2.0.20060429110036.02c01b98@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20060429110036.02c01b98@localhost> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060502:kclau60@netvigator.com::hMJMnlJCjsKOBc67:000000000000000 0000000000000000000000004yRM X-Hashcash: 1:20:060502:tgl@sss.pgh.pa.us::4OaIkhBUWE+XFYHY:00000000000000000000 0000000000000000000000000RaB X-Hashcash: 1:20:060502:pgsql-performance@postgresql.org::iJ3MbZH2bqT1XRrM:00000 00000000000000000000000018Bu X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/41 X-Sequence-Number: 18828 On Sat, Apr 29, 2006 at 11:18:10AM +0800, K C Lau wrote: > > At 10:39 06/04/29, Tom Lane wrote: > >K C Lau writes: > >> Without knowing the internals, I have this simplistic idea: if Postgres > >> maintains the current lowest transaction ID for all active > >transactions, it > >> probably could recycle dead tuples on the fly. > > > >[ yawn... ] Yes, we've heard that before. The hard part is getting rid > >of index entries. > > > > regards, tom lane > > I apologize for simplistic ideas again. I presume that the equivalent tuple > header information is not maintained for index entries. What if they are, > probably only for the most commonly used index types to allow recycling > where possible? The extra space required would be recycled too. It would > probably also help save a trip to the tuple data pages to determine the > validity of index entries during index scans. You should read through the -hacker archives, most of this stuff has been gone over multiple times. Storing tuple header info in indexes would be a huge drawback, as it would result in about 20 extra bytes per index entry. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461