Re: [GENERAL] Query is not using index when it should

От: Michael Fuhr
Тема: Re: [GENERAL] Query is not using index when it should
Дата: ,
Msg-id: 20041211162539.GA66539@winnie.fuhr.org
(см: обсуждение, исходный текст)
Ответ на: Re: [GENERAL] Query is not using index when it should  ("Steinar H. Gunderson")
Список: pgsql-performance

Скрыть дерево обсуждения

Re: [GENERAL] Query is not using index when it should  (Stephan Szabo, )
 Re: [GENERAL] Query is not using index when it should  ( (Tomas Skäre), )
  Re: [GENERAL] Query is not using index when it should  ("Steinar H. Gunderson", )
   Re: [GENERAL] Query is not using index when it should  (Michael Fuhr, )
   Re: [GENERAL] Query is not using index when it should  ( (Tomas Skäre), )

On Sat, Dec 11, 2004 at 03:32:13PM +0100, Steinar H. Gunderson wrote:
> On Sat, Dec 11, 2004 at 03:17:13PM +0100, Tomas Skäre wrote:
> > select c.* from cjm_object c
> >  inner join
> >   (select max(timestamp) as timestamp,objectid,field from cjm_object
> >    group by objectid,field) t
> >   using(timestamp,objectid,field)
> >  where 1=1 and data is not null
> >  order by objectid,field;
>
> Usually, SELECT max(field) FROM table is better written in PostgreSQL as
> SELECT field FROM table ORDER field DESC LIMIT 1.
>
> I don't see the point of "where 1=1", though...

I've seen that in generated queries.  The generating program uses
"WHERE 1=1" to simplify the addition of other conditions: instead
of checking if it needs to add a WHERE and putting ANDs in the right
places, it simply appends subsequent conditions with " AND condition".

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/


В списке pgsql-performance по дате сообщения:

От: Tom Lane
Дата:
Сообщение: Re: LIMIT causes SEQSCAN in subselect
От: tomas@nocrew.org (Tomas Skäre)
Дата:
Сообщение: Re: [GENERAL] Query is not using index when it should