Re: Table partitioning for maximum speed?

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Jeff Boes <jboes(at)nexcerpt(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Table partitioning for maximum speed?
Date: 2003-10-10 18:10:28
Message-ID: 20031010181028.GA30384@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Oct 10, 2003 at 13:40:17 -0400,
Jeff Boes <jboes(at)nexcerpt(dot)com> wrote:
>
> So, again: will front-loading the work by mapping the original query to
> 16 (or 256) different queries by examining the first digit save us
> anything? (My colleague who came up with this idea thinks so, since the
> calculation will be done on a box other than the database host, and even
> one disk access saved per query would outweigh the calculation.)

This could potentially save you some disk accesses. If the index is mostly
in cache now, you might not get a noticable benefit.

> Will having 15 (or 255) additional tables make the cache behave
> differently? Is there overhead associated with having another 15 (or
> 255) tables?

I am not sure whether or not you would use significantly more space
by having multiple tables.

The data format change suggested by someone else may be worth trying
as well. In addition to their suggestions, you might experiment with
keeping the hash in either 4 ints or 2 bigints. If you use bigints,
you could probably just use an index on one of the bigints and have
only a small chance of finding more than one row that matches.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Network Administrator 2003-10-10 18:20:21 Re: Interfaces that support cursors
Previous Message Nick Barr 2003-10-10 18:08:59 Re: go for a script! / ex: PostgreSQL vs. MySQL