Re: Is there any limitations

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Richard Huxton <richardh(at)archonet(dot)com>
Cc: li li <lili(at)cs(dot)uoregon(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Is there any limitations
Date: 2002-12-04 12:23:41
Message-ID: 1039004621.26887.20.camel@huli
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 2002-12-04 at 09:29, Richard Huxton wrote:
> On Tuesday 03 Dec 2002 7:49 pm, li li wrote:
> > > It depends on what you're going to do. If the idea is to join across
> > > the tables, it'll probably perform worse than just ahving a large
> > > table. OTOH, if what you're doing is, say, archiving from time to
> > > time, it doesn't seem unreasonable.
> >
> > The purpose for this design is to avoid record lookup in a huge table.
> > I expect to see the query results in, say, one minute, by searching a much
> > smaller table (not join across multiple tables).
> >
> > Thanks and regards.
>
> If you only want *most* queries to finish in one minute - I've used two tables
> in the past. One for recent info (which is what most of my users wanted) and
> one for older info (which only got accessed rarely). You're only union-ing
> two tables then and you can cluster the older table as mentioned elsewhere.

ANother approach could be to have index on timestamp field (which should
be naturally clustered) and search in recent data only.

If the problem is simply too much data returned, you could use LIMIT.

--
Hannu Krosing <hannu(at)tm(dot)ee>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2002-12-04 20:28:46 Re: Low Budget Performance, Part 2
Previous Message Richard Huxton 2002-12-04 09:29:53 Re: Is there any limitations