Re: Table partitioning for maximum speed? - Mailing list pgsql-general

From Bruno Wolff III
Subject Re: Table partitioning for maximum speed?
Date
Msg-id 20031010181028.GA30384@wolff.to
Whole thread Raw
In response to Re: Table partitioning for maximum speed?  (Jeff Boes <jboes@nexcerpt.com>)
Responses Re: Table partitioning for maximum speed?  (Greg Stark <gsstark@mit.edu>)
Re: Table partitioning for maximum speed?  (Joe Conway <mail@joeconway.com>)
List pgsql-general
On Fri, Oct 10, 2003 at 13:40:17 -0400,
  Jeff Boes <jboes@nexcerpt.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.

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Table partitioning for maximum speed?
Next
From: Doug McNaught
Date:
Subject: Re: Interfaces that support cursors