From: | Tom Smith <tomsmith1989sk(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: BRIN Usage |
Date: | 2016-02-18 18:37:37 |
Message-ID: | CAKwSVFG2RsVaPE1VZYSvrUbUktOFTQbkOgJAOjbBwLJ0-9cSXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
it is for reducing index size as the table become huge.
sorry for confusion, by timestamp, I meant a time series number, not the
sql timestamp type.
I need the unique on the column to ensure no duplicate, but the btree
index is getting
huge so BRIN seems to solve problem but can not ensure unique
On Thu, Feb 18, 2016 at 2:14 AM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:
>
> On 18/02/2016 9:34 am, "Tom Smith" <tomsmith1989sk(at)gmail(dot)com> wrote:
> >
> > Hi:
> >
> > I feel it is a stupid question.
> >
> > Can BRIN index enforce uniqueness?
> > My issue is
> > the column I'd like to apply BRIN index also needs to be unique
> > (think of timestamp as primary key).
>
> Only btree supports unique.
> Is there a special reason not to use btree? I'm also finding it hard to
> imagine a case where a timestamp primary key is a good idea.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Rakesh Kumar | 2016-02-18 20:02:50 | Re: Multiple databases and shared_buffers |
Previous Message | Kevin Wooten | 2016-02-18 17:33:13 | Re: JDBC behaviour |