pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: John A Meinel <john@arbash-meinel.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: linux@alteeve.com
Cc: tgl@sss.pgh.pa.us
Cc: tobias@nordicbet.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Index ot being used
Date: Mon, 13 Jun 2005 09:51:57 -0500
Message-ID: <42AD9D8D.9060503@arbash-meinel.com> (raw)
In-Reply-To: <s2ad532e.099@gwmta.wicourts.gov>
References: <s2ad532e.099@gwmta.wicourts.gov>

Kevin Grittner wrote:

>It sure would be nice if the optimizer would consider that it had the
>leeway to add any column which was restricted to a single value to any
>point in the ORDER BY clause.  Without that, the application programmer
>has to know what indexes are on the table, rather than being able to
>just worry about the set of data they want.  Obviously, if a column can
>have only one value in the result set, adding to any point in the ORDER
>BY can't change anything but performance.  That sure sounds like
>something which should fall within the scope of an optimizer.
>
>It really should be a DBA function to add or drop indexes to tune the
>performance of queries, without requiring application programmers to
>modify the queries for every DBA adjustment.  (When you have a database
>with over 350 tables and thousands of queries, you really begin to
>appreciate the importance of this.)
>
>
I agree that having a smarter optimizer, which can recognize when an
index can be used for ORDER BY would be useful.

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.

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.

I'm guessing the optimization wasn't as important as some of the others
that have been done, so it hasn't been implemented yet.

John
=:->

Attachments:

  signature.asc (application/pgp-signature, 252B) download

view thread (31+ messages)  latest in thread

Message-ID: <42AD9D8D.9060503@arbash-meinel.com>
Permalink:  ../42AD9D8D.9060503@arbash-meinel.com/
Also on:    postgresql.org/message-id/42AD9D8D.9060503@arbash-meinel.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: john@arbash-meinel.com, Kevin.Grittner@wicourts.gov, linux@alteeve.com, tgl@sss.pgh.pa.us, tobias@nordicbet.com
  Subject: Re: Index ot being used
  In-Reply-To: <42AD9D8D.9060503@arbash-meinel.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox