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: | Raw Message | Whole Thread | 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 |