Re: BUG #7629: Suboptimal query plan when index search is possible and an additional search operator is given.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dmigowski(at)ikoffice(dot)de
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7629: Suboptimal query plan when index search is possible and an additional search operator is given.
Date: 2012-10-30 14:29:56
Message-ID: 10946.1351607396@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

dmigowski(at)ikoffice(dot)de writes:
> However, when I also want to order by id:
> order by prep_natural_sort(d.number) ASC,
> d.id ASC
> it does a sequential scan.

Sure. That index doesn't satisfy this sort order. (It could have
gotten chosen anyway, if the partial-index predicate were selective
enough, but evidently it isn't.)

> This is a bit stupid, also because the relevant data could be fetched very
> fast by the first order-by expression, and then the results could be ordered
> again, which is then much faster than doing a full sequential scan on the
> data.

That's an unsupported assertion, which we'd have to write a great deal
of code before we could even test. There are a lot of more useful
places to spend hacking time, with greater assurance of the work not
being wasted.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Dae-man Yang 2012-10-31 03:09:16 initdb using option "username" startup log
Previous Message Louis-Claude Canon 2012-10-30 13:35:36 Re: BUG #7623: Inconsistency on transaction isolation documentation