X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 05A16329E91 for ; Wed, 15 Sep 2004 08:07:08 +0100 (BST) 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 96576-05 for ; Wed, 15 Sep 2004 07:07:01 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 6244B329ECF for ; Wed, 15 Sep 2004 08:07:01 +0100 (BST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i8F76xCp097709 for ; Wed, 15 Sep 2004 07:07:00 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i8F6o6ED092515 for pgsql-performance@postgresql.org; Wed, 15 Sep 2004 06:50:06 GMT From: Christopher Browne X-Newsgroups: comp.databases.postgresql.performance Subject: Re: Data Warehouse Reevaluation - MySQL vs Postgres -- Date: Wed, 15 Sep 2004 02:15:08 -0400 Organization: cbbrowne Computing Inc Lines: 19 Message-ID: References: <20040914223333.GL56059@decibel.org> <60k6uw1cqa.fsf@dev6.int.libertyrms.info> <4147C560.9060702@joeconway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org X-message-flag: Outlook is rather hackable, isn't it? X-Home-Page: http://www.cbbrowne.com/info/ X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) Cancel-Lock: sha1:leQavVXTFA3MVhkRH/tTHsl37po= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200409/137 X-Sequence-Number: 8265 In the last exciting episode, mail@joeconway.com (Joe Conway) wrote: > That's exactly what we're doing, but using inherited tables instead of > a union view. With inheritance, there is no need to rebuild the view > each time a table is added or removed. Basically, in our application, > tables are partitioned by either month or week, depending on the type > of data involved, and queries are normally date qualified. Sounds interesting, and possibly usable. Where does the constraint come in that'll allow most of the data to be excluded? Or is this just that the entries are all part of "bigtable" so that the self join is only 2-way? -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://linuxfinances.info/info/advocacy.html "Be humble. A lot happened before you were born." - Life's Little Instruction Book