| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | John A Meinel <john(at)arbash-meinel(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, linux(at)alteeve(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, tobias(at)nordicbet(dot)com, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Index ot being used |
| Date: | 2005-06-13 15:48:34 |
| Message-ID: | 20050613154834.GA9203@wolff.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Jun 13, 2005 at 09:51:57 -0500,
John A Meinel <john(at)arbash-meinel(dot)com> wrote:
>
> I don't know if there are specific reasons why not, other than just not
> being implemented yet. It might be tricky to get it correct (for
> instance, how do you know which columns can be added, which ones will be
> constant) Perhaps you could just potentially add the WHERE items if they
> have an equality constraint with a constant. But I'm guessing there are
> more cases than that where the optimization could be performed.
I think there is already some intelligence about which expressions are
constant in particular parts of a plan.
I think you need to be able to do two things. One is to drop constant
expressions from order by lists. The other is when looking for an index
to produce a specific ordering, to ingore leading constant expressions
when comparing to the order by expressions.
> Also, the more options you give the planner, the longer it takes on
> average to plan any single query. Yes, it is beneficial for this use
> case, but does that balance out slowing down all the other queries by a
> tiny bit.
But there aren't that many possible indexes, so I don't expect this will
slow things down much more than the current check for potentially useful
indexes.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yves Vindevogel | 2005-06-13 15:49:47 | Fwd: Updates on large tables are extremely slow |
| Previous Message | Wei Weng | 2005-06-13 15:47:30 | Re: PostgreSQL using the wrong Index |