Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TWSVO-0006Xu-Ri for pgsql-performance@postgresql.org; Thu, 08 Nov 2012 13:50:51 +0000 Received: from mail-lb0-f174.google.com ([209.85.217.174]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TWSVN-0003rG-D1 for pgsql-performance@postgresql.org; Thu, 08 Nov 2012 13:50:50 +0000 Received: by mail-lb0-f174.google.com with SMTP id n3so2177622lbo.19 for ; Thu, 08 Nov 2012 05:50:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=cRHljnS5k0seEbIMvgyKsBCipAC9Efl2p+qyvk3WUro=; b=HVskAgjLRGrp3KwmlGX/ubVLEpSJeSOUhmmtH6cc3kcd94+1rr9Y4WoYV9IOWWDUjZ 86i5y6rxA2oUxtj514Ruq2Bww4TSr5CeedBrzOwcufp1Ca1hxr71GLSrAEz8Ll/sbPIh jY+dDbHlTsZoFf2hPl1VMjc8fZpGO3twM5zt8/XSBqHgA5PIvjPcHAiJNBQmoqWma7sC 5qd+hpGkgmRALnqiRcd3DK0KEwsDQmkw6MC/uT6hLPwz0YscPVNaaojb4pNl9c7tdFZK i7JWtlc6RCSItFyVPUUmwgvJVPEHEucsRs3v0VxJPvr1E0jsTP17BFKzJf9I1SSuAEUx y3tg== Received: by 10.112.45.231 with SMTP id q7mr3296977lbm.133.1352382647332; Thu, 08 Nov 2012 05:50:47 -0800 (PST) Received: from [192.168.41.201] (host81-142-153-89.in-addr.btopenworld.com. [81.142.153.89]) by mx.google.com with ESMTPS id f3sm9226621lbm.11.2012.11.08.05.50.46 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 05:50:46 -0800 (PST) Message-ID: <509BB8B5.9080308@optrak.com> Date: Thu, 08 Nov 2012 13:50:45 +0000 From: Mark Thornton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Denis CC: pgsql-performance@postgresql.org Subject: Re: Thousands databases or schemas References: <1352367376704-5731189.post@n5.nabble.com> In-Reply-To: <1352367376704-5731189.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk6ZgIjBuRqp/vn6Bt1rMcg9gACIBEEEdEBawOkcurIrFMH257akH00dYUdRIy5BNHg4a/p X-Pg-Spam-Score: -1.5 (-) X-Archive-Number: 201211/109 X-Sequence-Number: 48475 On 08/11/12 09:36, Denis wrote: > We have a web application where we create a schema or a database with a > number of tables in it for each customer. Now we have about 2600 clients. > > The problem we met using a separate DB for each client is that the creation > of new DB can take up to 2 minutes, that is absolutely unacceptable. Using > schemes instead (one DB with a number of schemes containing similar tables > in it) solved this problem (schemes are created in a couple of seconds), but > created two other blocking points: > 1. sometimes creation of a new table in a schema takes up to 5 seconds. In > case when we have create up to 40 tables in a schema this takes way too much > time. > 2. "pg_dump -n schema_name db_name" takes from 30 to 60 seconds, no matter > how big is the amount of data in the schema. Also, the dump of the tables > structure only takes at least 30 seconds. Basing on this topic > http://postgresql.1045698.n5.nabble.com/pg-dump-and-thousands-of-schemas-td5709766i60.html, > pg_dump always analyses ALL the tables in the DB, i.e. in my case more than > 100 000 tables. The obvious solution would be to write your own version of pg_dump which only examines the tables within a schema. You can even start with the source of the standard pg_dump! However, you could then eliminate the per customer schema/tables and add an extra 'customer' key column on each table. Now you modify pg_dump to only dump the parts of each table matching a given customer id. Mark Thornton