X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D80BCD9411 for ; Sat, 24 Sep 2005 02:15:08 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 12574-03 for ; Sat, 24 Sep 2005 05:15:05 +0000 (GMT) Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [202.0.58.21]) by svr1.postgresql.org (Postfix) with ESMTP id 853D5D940A for ; Sat, 24 Sep 2005 02:15:02 -0300 (ADT) Received: from smtp-1.paradise.net.nz (smtp-1a.paradise.net.nz [202.0.32.194]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0INB003RQ2L1Q1@linda-2.paradise.net.nz> for pgsql-performance@postgresql.org; Sat, 24 Sep 2005 17:15:02 +1200 (NZST) Received: from [192.168.1.11] (218-101-45-243.paradise.net.nz [218.101.45.243]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id 9BB50828A3; Sat, 24 Sep 2005 17:15:01 +1200 (NZST) Date: Sat, 24 Sep 2005 17:14:59 +1200 From: Mark Kirkwood Subject: Re: SELECT LIMIT 1 VIEW Performance Issue In-reply-to: <6.2.1.2.0.20050924105728.05388920@localhost> To: K C Lau Cc: pgsql-performance@postgresql.org Message-id: <4334E0D3.1080504@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) References: <6EE64EF3AB31D5448D0007DD34EEB3417DD406@Herge.rcsinc.local> <6.2.1.2.0.20050923155952.05889a50@localhost> <4334AE89.8060806@paradise.net.nz> <6.2.1.2.0.20050924105728.05388920@localhost> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.126 required=5 tests=[AWL=0.126] X-Spam-Level: X-Archive-Number: 200509/321 X-Sequence-Number: 14629 K C Lau wrote: > I'm wondering if this performance issue is common enough for other users > to merit a fix in pg, especially as it seems that with MVCC, each of the > data records need to be accessed in addition to scanning the index. > Yes - there are certainly cases where index only access (or something similar, like b+tree tables) would be highly desirable. From what I have understood from previous discussions, there are difficulties involved with producing a design that does not cause new problems... regards Mark