Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id EE9DE2E003A for ; Wed, 21 May 2008 16:15:12 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 99564-10 for ; Wed, 21 May 2008 16:14:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net [204.127.217.101]) by developer.postgresql.org (Postfix) with ESMTP id 131F12E0072 for ; Wed, 21 May 2008 16:14:58 -0300 (ADT) Received: from [127.0.0.1] (adsl-4-175-99.gsp.bellsouth.net[65.4.175.99]) by isp.att.net (frfwmhc01) with ESMTP id <20080521191453H0100b7j7de>; Wed, 21 May 2008 19:14:54 +0000 X-Originating-IP: [65.4.175.99] Message-ID: <483474AB.4040807@reedyriver.com> Date: Wed, 21 May 2008 15:14:51 -0400 From: "H. Hall" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: "Big O" notation for postgres? References: <48342D6D.1020506@reedyriver.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200805/301 X-Sequence-Number: 30269 PFC wrote: > On Wed, 21 May 2008 16:10:53 +0200, H. Hall wrote: > >> Does anyone know if there is a source that provides "Big O" notation >> for postgres's aggregate functions and operations? For example is >> count(*) = O(1) or O(n)? >> >> Do the developers for postgres use Big O when selecting algorithms? >> If so, is the info easily available? > > You can't do any better than O( n rows examined by the aggregate ) > except for max() and min() on an indexed expression, which in this > case aren't really aggrgates anymore since they are internally > rewritten as an index lookup to get the value you want... but stuff > like sum() or avg() or count() will always have to see all the rows > selected (and some more) unless you use clever hacks like materialized > views etc, in which case the thing in the O() will change, or at least > the O() constant will change... > Thank you PFC and also Jonah, and Richard for your replies. It occurs to me that Big O might be a useful way to understand/explain what is happening with situations like Albert's earlier today: I've got a query similar to this: > > > > select * from t1, t2 where t1.id > 158507 and t1.id = t2.id; > > > > That took > 84 minutes (the query was a bit longer but this is the part > > that made the difference) after a little change the query took ~1 second: > > > > select * from t1, t2 where t1.id > 158507 and t2.id > 158507 and t1.id = > > t2.id; BTW, anyone reading this and not familiar with Big O notation might want to check out these links. All are intro type articles: * An informal introduction to O(N) notation: http://www.perlmonks.org/?node_id=227909 * Analysis of Algorithms and Selection of Algorithms: http://www.cs.utk.edu/~parker/Courses/CS302-Fall06/Notes/complexity.html * Complexity and Big-O Notation http://pages.cs.wisc.edu/~hasti/cs367-common/notes/COMPLEXITY.html -- H. Hall ReedyRiver Group LLC http://www.reedyriver.com