X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 15211DA7FD for ; Tue, 25 Oct 2005 13:03:52 -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 29493-06 for ; Tue, 25 Oct 2005 16:03:35 +0000 (GMT) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.195]) by svr1.postgresql.org (Postfix) with ESMTP id C37ADDACF5 for ; Tue, 25 Oct 2005 13:03:19 -0300 (ADT) Received: by qproxy.gmail.com with SMTP id v28so521378qbe for ; Tue, 25 Oct 2005 09:03:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=l+aX6yYc0ey4AmrPaS8sGd0p96HgpEKWqx4GmHZfQ/YRNigfst7Hm8uMppPejL5vHJSEbflrm/1fy2jzW9QyPKnfndM/Sp3NavnBgPO4k59SLFslVYQKIoUJ+movvX/Rdcby1/+akNzWvvVsN3PbNORX2cUzs/315EDOQ8Wm1/A= Received: by 10.64.53.20 with SMTP id b20mr1531142qba; Tue, 25 Oct 2005 09:03:19 -0700 (PDT) Received: by 10.65.240.20 with HTTP; Tue, 25 Oct 2005 09:03:19 -0700 (PDT) Message-ID: <3cf983d0510250903l6eb5b3dfsda46190f3e7fd289@mail.gmail.com> Date: Tue, 25 Oct 2005 16:03:19 +0000 From: Rodrigo Madera To: =?ISO-8859-1?Q?N=F6rder-Tuitje=2C_Marcus?= Subject: Re: Inefficient escape codes. Cc: pgsql-performance@postgresql.org In-Reply-To: <16F953410A0F1346848DCB476A989CFE01D56C@swtexchange2.technology.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6165_8123633.1130256199753" References: <16F953410A0F1346848DCB476A989CFE01D56C@swtexchange2.technology.de> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.325 required=5 tests=[AWL=0.205, HTML_50_60=0.095, HTML_MESSAGE=0.001, RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200510/366 X-Sequence-Number: 15134 ------=_Part_6165_8123633.1130256199753 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ok, thanks for the limits info, but I have that in the manual. Thanks. But what I really want to know is this: 1) All large objects of all tables inside one DATABASE is kept on only one table. True or false? Thanks =3Do) Rodrigo On 10/25/05, N=F6rder-Tuitje, Marcus wrote: > > oh, btw, no harm, but : > having 5000 tables only to gain access via city name is a major design > flaw. > you might consider putting all into one table working with a distributed > index over yer table (city, loc_texdt, blobfield); creating a partitioned > index over city. > best regards > > -----Urspr=FCngliche Nachricht----- > *Von:* pgsql-performance-owner@postgresql.org [mailto: > pgsql-performance-owner@postgresql.org]*Im Auftrag von *Rodrigo Madera > *Gesendet:* Montag, 24. Oktober 2005 21:12 > *An:* pgsql-performance@postgresql.org > *Betreff:* Re: [PERFORM] Inefficient escape codes. > > Now this interests me a lot. > > Please clarify this: > > I have 5000 tables, one for each city: > > City1_Photos, City2_Photos, ... City5000_Photos. > > Each of these tables are: CREATE TABLE CityN_Photos (location text, lo_id > largeobectypeiforgot) > > So, what's the limit for these large objects? I heard I could only have 4 > billion records for the whole database (not for each table). Is this true= ? > If this isn't true, then would postgres manage to create all the large > objects I ask him to? > > Also, this would be a performance penalty, wouldn't it? > > Much thanks for the knowledge shared, > Rodrigo > > > ------=_Part_6165_8123633.1130256199753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ok, thanks for the limits info, but I have that in the manual. Thanks.

But what I really want to know is this:

1) All large objects of all tables inside one DATABASE is kept on only one = table. True or false?

Thanks =3Do)
Rodrigo

On 10/25/05, N=F6rder-Tuitje, Marcus <noerder-tuitje@technology.de> wrote:
oh,=20 btw, no harm, but :
=  
having=20 5000 tables only to gain access via city name is a major design=20 flaw.
=  
you=20 might consider putting all into one table working with a distributed i= ndex=20 over yer table (city, loc_texdt, blobfield); creating a partitioned index o= ver=20 city.
=  = ;
best=20 regards
-----Urs= pr=FCngliche Nachricht-----
Von:=20 pgsql-performan= ce-owner@postgresql.org=20 [mailto:pgsql-= performance-owner@postgresql.org]Im Auftrag von Rodrigo=20 Madera
Gesendet: Montag, 24. Oktober 2005 21:12
An:= =20 pgsql-performance@pos= tgresql.org
Betreff: Re: [PERFORM] Inefficient=20 escape codes.

Now this interests me a lot.

Ple= ase=20 clarify this:

I have 5000 tables, one for each=20 city:

City1_Photos, City2_Photos, ... City5000_Photos.

Each= of=20 these tables are: CREATE TABLE CityN_Photos (location text, lo_id=20 largeobectypeiforgot)

So, what's the limit for these large objects= ? I=20 heard I could only have 4 billion records for the whole database (not for= each=20 table). Is this true? If this isn't true, then would postgres manage to c= reate=20 all the large objects I ask him to?

Also, this would be a performa= nce=20 penalty, wouldn't it?

Much thanks for the knowledge shared,
Rodrigo




------=_Part_6165_8123633.1130256199753--