Skip site navigation (1) Skip section navigation (2)

Re: One large v. many small

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: One large v. many small
Date: 2003-01-30 18:02:40
Message-ID: 20030130130240.I983@mail.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performance
On Thu, Jan 30, 2003 at 12:34:36PM -0500, Noah Silverman wrote:
> Select (*) from client_4 where foo=2;
> 
> A query from the new, proposed system would be
> 
> Select (*) from big_results where client=4 and foo=2.
> 
> The big questions is, WHICH WILL BE FASTER with Postgres.  Is there any 
> performance improvement or cost to switching to this new structure.

Faster overall, or faster for that operation?  I can't prove it, but
I suspect that the first one will return faster just because both the
index and the table itself is smaller.

The possibility is thatit will cause you problems overall, however,
because of the large number of files you have to keep if you use 3000
tables.  This is dependent on your filesytem (and its
implementation).  

Note, too, that a lot of transactions frequently updating the table
might make a difference.  A large number of dead tuples sitting on a
10 million row table will make anything crawl.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info>                              M2P 2A8
                                         +1 416 646 3304 x110


In response to

Responses

pgsql-performance by date

Next:From: Noah SilvermanDate: 2003-01-30 18:24:38
Subject: Re: One large v. many small
Previous:From: Josh BerkusDate: 2003-01-30 17:56:56
Subject: Re: One large v. many small

pgsql-general by date

Next:From: Noah SilvermanDate: 2003-01-30 18:24:38
Subject: Re: One large v. many small
Previous:From: Ron St.PierreDate: 2003-01-30 17:59:17
Subject: Re: Documentation needs significant improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group