From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | DM <dm(dot)aeqa(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Composite Index question |
Date: | 2010-10-21 00:10:41 |
Message-ID: | 4CBF8501.2000007@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
If you can think of one benefit from having the redundant index then by
all means keep it. It certainly eludes me. Seems to me, removing an
un-necessary index on a huge table can only be a good thing.
On 10/20/2010 06:02 PM, DM wrote:
> Its a huge table in production, i dont want to take any risk.
>
> I can simulate and test this but i was to checking to see If any one
> knows off hand about this.
>
>
>
> I can simulate it but
> On Wed, Oct 20, 2010 at 4:57 PM, Rob Sargent <robjsargent(at)gmail(dot)com
> <mailto:robjsargent(at)gmail(dot)com>> wrote:
>
> Hm. Run some queries; drop the second version of the index definition;
> re-run the same queries; report to the group. The redundant index isn't
> helping, that much is certain.
>
> On 10/20/2010 05:43 PM, DM wrote:
> > Composite Index question:
> >
> > I have composite index on 3 columns on a table, by mistake the
> composite
> > index was created twice on the table.
> >
> > Will there any performance issues on this table because of the 2 same
> > composite indexes?
> >
> > Thanks
> > Deepak
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org
> <mailto:pgsql-general(at)postgresql(dot)org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2010-10-21 00:19:14 | Re: Custom cache implemented in a postgresql C function |
Previous Message | DM | 2010-10-21 00:02:41 | Re: Composite Index question |