X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C9F8153539 for ; Tue, 3 May 2005 08:01:31 -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 09294-04 for ; Tue, 3 May 2005 11:01:28 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by svr1.postgresql.org (Postfix) with ESMTP id D79585352F for ; Tue, 3 May 2005 08:01:26 -0300 (ADT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DSv34-0008PU-Ak for pgsql-sql@postgresql.org; Tue, 03 May 2005 12:54:42 +0200 Received: from srv.protecting.net ([212.126.218.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 12:54:42 +0200 Received: from hf1122x by srv.protecting.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 May 2005 12:54:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: Harald Fuchs Subject: Re: Trimming the cost of ORDER BY in a simple query Date: 03 May 2005 12:59:48 +0200 Organization: Linux Private Site Lines: 10 Message-ID: References: <20050503043531.23516.qmail@web31106.mail.mud.yahoo.com> <1115104938.5853.25.camel@localhost.localdomain> Reply-To: hf1122x@protecting.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: srv.protecting.net User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.008 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/30 X-Sequence-Number: 21343 In article <1115104938.5853.25.camel@localhost.localdomain>, Ragnar Hafsta=F0 writes: > 20 ms does not sound like a big problem. > if 20 ms is really too much for you, and add_date IS a timestamp, > you might think about adding a date column , maintained > by triggers of by your application, and add an index on (user_id, x) Maybe a functional index on "date_trunc('day', add_date)" would be helpful?