Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 351639FB422 for ; Wed, 6 Jun 2007 17:20:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 36853-01 for ; Wed, 6 Jun 2007 17:20:14 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by postgresql.org (Postfix) with ESMTP id 5ED069FB408 for ; Wed, 6 Jun 2007 17:20:14 -0300 (ADT) Received: by wa-out-1112.google.com with SMTP id k40so404758wah for ; Wed, 06 Jun 2007 13:20:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O+UgAV6ul9pzhmrepjoNIoQ4VzSuQ/u5QKSeEjFs2QHRQiCJP2vz2Kx4Djdqc6AJHVvKPpRamO1teM3PKpBYaMzKdoX/0c+rib8ydxPC9Q5jsbmvV9VbCx4RRN7GsAfI9Rmt33+5n52DPOk19Yh8qdyo3Q3dCmdPc0OqEZ8OvpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BADTIZ2B7DBAEOzn+Dg7vOr2pkKvxYhnz8/LW0wj9tVzHie96Wal5BRWedco7smXSN6r28vJuTm3jo4Z9fQuZbCRzmIBQlKuAuCWSFEDZ0GgQpKHPj3LKekGaRZckxS6/BO5zKQiZWrQWfJF7c4yRhG15frH626myKGVjhP0DD8= Received: by 10.114.79.1 with SMTP id c1mr757945wab.1181161213025; Wed, 06 Jun 2007 13:20:13 -0700 (PDT) Received: by 10.114.183.2 with HTTP; Wed, 6 Jun 2007 13:20:12 -0700 (PDT) Message-ID: <36e682920706061320k6c8eb88etf8be1ce359feda11@mail.gmail.com> Date: Wed, 6 Jun 2007 16:20:12 -0400 From: "Jonah H. Harris" To: "Craig James" Subject: Re: Thousands of tables versus on table? Cc: pgsql-performance@postgresql.org In-Reply-To: <4667157C.5000208@emolecules.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <466593E5.1010904@g2switchworks.com> <87sl96z0wf.fsf@oxford.xeocode.com> <10525.1181080765@sss.pgh.pa.us> <4666DF99.3010809@emolecules.com> <36e682920706061101i5d3344c2idc518c6190b0af77@mail.gmail.com> <4667157C.5000208@emolecules.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/109 X-Sequence-Number: 25142 On 6/6/07, Craig James wrote: > You didn't read my message. I said that *BOTH* Oracle > and Postgres performed well with table-per-customer. Yes, I did. My belief is that Oracle can handle all customers in a single table. > The technical question is simple: Table-per-customer or > big-table-for-everyone. The answer is, "it depends." I agree, it does depend on the data, workload, etc. No one-size-fits-all answer there. > The reason I assert (and stand by this) that "They're > blowing smoke" when they claim Oracle has the magic > cure, is because Oracle and Postgres are both relational > databases, they write their data to disks, and they both > have indexes with O(log(N)) retrieval/update times. Oracle > doesn't have a magical workaround to these facts, > nor does Postgres. Agreed that they are similar on the basics, but they do use significantly different algorithms and optimizations. Likewise, there is more tuning that can be done with Oracle given the amount of time and money one has to spend on it. Again, cost/benefit analysis on this type of an issue... but you're right, there is no "magic cure". -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/