X-Original-To: pgsql-general@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 8DBDE474E44; Tue, 15 Apr 2003 10:23:42 -0400 (EDT) Received: from candle.pha.pa.us (momjian.navpoint.com [207.106.42.251]) by postgresql.org (Postfix) with ESMTP id AB4F34758F1; Tue, 15 Apr 2003 10:23:37 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id h3FENUf06986; Tue, 15 Apr 2003 10:23:30 -0400 (EDT) From: Bruce Momjian Message-Id: <200304151423.h3FENUf06986@candle.pha.pa.us> Subject: Re: [PERFORM] Yet Another (Simple) Case of Index not used In-Reply-To: <3E93348C.20208@cvc.net> To: gearond@cvc.net Date: Tue, 15 Apr 2003 10:23:30 -0400 (EDT) Cc: Dann Corbit , Denis , pgsql-performance@postgresql.org, pgsql-general@postgresql.org, pgsql-sql@postgresql.org X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/886 X-Sequence-Number: 40951 Dennis Gearon wrote: > from mysql manual: > ------------------------------------------------------------- > "COUNT(*) is optimized to return very quickly if the SELECT retrieves from one > table, no other columns are retrieved, and there is no WHERE clause. For example: > > mysql> select COUNT(*) from student;" > ------------------------------------------------------------- > > A nice little optimization, maybe not possible in a MVCC system. I think the only thing you can do with MVCC is to cache the value and tranaction id for "SELECT AGG(*) FROM tab" and make the cached value visible to transaction id's greater than the one that executed the query, and invalidate the cache every time the table is modified. In fact, don't clear the cache, just record the transaction id of the table modification command so we can use standard visibility routines to make the cache usable as long as possiible. The cleanest way would probably be to create an aggregate cache system table, and to insert into it when someone does an unqualified aggregate, and to delete from it when someone modifies the table --- the MVCC tuple visibility rules are handled automatically. Queries can look in there to see if a visible cached value already exists. Of course, the big question is whether this would be a big win, and whether the cost of upkeep would justify it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073