Re: Choosing an index on partitioned tables.

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Brent Wood <Brent(dot)Wood(at)niwa(dot)co(dot)nz>, Tim Uckun <timuckun(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Choosing an index on partitioned tables.
Date: 2021-09-07 07:24:21
Message-ID: 4d365d854c7759b72549540f38c66ba8ecfe229a.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 2021-09-07 at 04:06 +0000, Brent Wood wrote:
> From: Tim Uckun <timuckun(at)gmail(dot)com>
> > My plan is to partition by date ranges which means the primary key has
> > to include the timestamp column and the id column  As far as I know
> > there is no way to specify an index type for those columns.
> >
> > The metric type is a text column and will not be very selective. It
> > will have somewhere around 200 types of metrics and they will all be
> > short, less than ten characters.
> >
> > Given that there will be a lot of records I was wondering what type of
> > index would be ideal for that column. Seems like hash indexes would be
> > ideal because only comparison will be = and they are smaller than
> > Btrees but for a while they were not recommended.
> >
> > Would hash be the best or would something work better?
>
> I've had good success with TimescaleDB for large timesries databases (40b readings).

That has nothing to do with indexing, and I would think twice to install
an invasive extension like that and add a dependency on third-party code,
just because I want to partition a table.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Raul Kaubi 2021-09-07 07:43:07 How to log bind values for statements that produce errors
Previous Message Laurenz Albe 2021-09-07 07:21:24 Re: Choosing an index on partitioned tables.