Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 772519FBC0E for ; Thu, 22 Mar 2007 14:27:41 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 16833-02 for ; Thu, 22 Mar 2007 14:27:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from service-web.de (p15093784.pureserver.info [217.160.106.224]) by postgresql.org (Postfix) with ESMTP id 606479FBB25 for ; Thu, 22 Mar 2007 14:27:33 -0300 (ADT) Received: from [145.228.94.105] (unknown [145.228.94.105]) by service-web.de (Postfix) with ESMTP id 4D13A200099; Thu, 22 Mar 2007 18:27:33 +0100 (CET) Message-ID: <4602BC84.8030101@wildenhain.de> Date: Thu, 22 Mar 2007 18:27:32 +0100 From: Tino Wildenhain User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Craig A. James" Cc: pgsql-performance@postgresql.org Subject: Re: Performance of count(*) References: <200703221208.19358.albert@sedifa.com> <20070322141807.GE11402@mathom.us> <46029DE3.9030505@modgraph-usa.com> <4602A15B.7000908@wildenhain.de> <4602BB19.9050306@modgraph-usa.com> In-Reply-To: <4602BB19.9050306@modgraph-usa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/343 X-Sequence-Number: 23748 Craig A. James schrieb: > Tino Wildenhain wrote: >> Craig A. James schrieb: >> ... >>> In our case (for a variety of reasons, but this one is critical), we >>> actually can't use Postgres indexing at all -- we wrote an entirely >>> separate indexing system for our data... >> >> ...There is no need to store or >> maintain this information along with postgres when you can store >> and maintain it directly in postgres as well. > > Whether we store our data inside or outside Postgres misses the point > (in fact, most of our data is stored IN Postgres). It's the code that > actually performs the index operation that has to be external to Postgres. > >> On top of that, postgres has a very flexible and extensible index >> system. > > You guys can correct me if I'm wrong, but the key feature that's missing > from Postgres's flexible indexing is the ability to maintain state > across queries. Something like this: > > select a, b, my_index_state() from foo where ... > offset 100 limit 10 using my_index(prev_my_index_state); > Yes, you are wrong :-) The technique is called "CURSOR" if you maintain persistent connection per session (e.g. stand allone application or clever pooling webapplication) If its a naive web application you just store your session in tables where you can easily maintain the scroll state as well. Regards Tino