Skip site navigation (1) Skip section navigation (2)

Re: Using more tha one index per table

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Rob Wultsch <wultsch(at)gmail(dot)com>
Cc: "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Using more tha one index per table
Date: 2010-07-21 08:03:28
Message-ID: AANLkTilGwVkxsvBoPlJ4h25QrC4z7pqvBCMBqB_-ef5y@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-performance
On Wed, Jul 21, 2010 at 1:58 AM, Rob Wultsch <wultsch(at)gmail(dot)com> wrote:
> On Wed, Jul 21, 2010 at 12:53 AM, A. Kretschmer
> <andreas(dot)kretschmer(at)schollglas(dot)com> wrote:
>>
>> In response to Elias Ghanem :
>> > Hi,
>> > I have a question concerning the uses of indexes in Postgresql.
>> > I red that in PG a query can not use more than one index per table: "a
>> > query or
>> > data manipulation command can use at most one index per table".
>>
>> That's not true, but it's true for MySQL, afaik.
>>
>
> That is not true either, though MySQL is less good at using bitmap'ed
> indexes. 5.0 can use "merge indexes",

Yeah, the biggest problem MySQL has is that it's got a pretty
simplistic query planner so it often makes poor choices.

Note that PostgreSQL on the other hand, has a much smarter query
planner.  So it usually makes better choices.  But when it makes a
wrong one, it can be a doozie.  Luckily, reported strange behavior in
the query planner is usually fixed pretty quickly.

In response to

pgsql-docs by date

Next:From: Marc CousinDate: 2010-07-21 12:41:17
Subject: error in oracle to plpgsql documentation ?
Previous:From: Scott MarloweDate: 2010-07-21 08:01:00
Subject: Re: Using more tha one index per table

pgsql-performance by date

Next:From: stanimir petrovDate: 2010-07-21 12:42:04
Subject: tune memory usage for master/slave nodes in cluster
Previous:From: Scott MarloweDate: 2010-07-21 08:01:00
Subject: Re: Using more tha one index per table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group