Re: name search query speed

Поиск
Список
Период
Сортировка
От Jeremiah Jahn
Тема Re: name search query speed
Дата
Msg-id 1109882849.16326.99.camel@bluejay.goodinassociates.com
обсуждение исходный текст
Ответ на Re: name search query speed  ("Dave Held" <dave.held@arrayservicesgrp.com>)
Ответы Re: name search query speed  (Markus Schaber <schabi@logix-tt.com>)
Список pgsql-performance
doesn't that cause two queries? I used to do it that way and cut my time
substantially by counting in-line. Even though the results were cached
it still took more time. Also since the tables is constantly be updated
the returned total would not always match the number of results on the
second query.

On Thu, 2005-03-03 at 14:26 -0600, Dave Held wrote:
> > -----Original Message-----
> > From: Jeremiah Jahn [mailto:jeremiah@cs.earlham.edu]
> > Sent: Thursday, March 03, 2005 2:15 PM
> > To: John A Meinel
> > Cc: postgres performance
> > Subject: Re: [PERFORM] name search query speed
> >
> > [...]
> > So the count for this is generated on the fly needed for
> > pagination in the app which expresses the total number of
> > finds, but only displays 40 of them. If any one knows a way
> > to determine the total number of matches without needing to
> > iterate through them using jdbc, I'm all ears as this would
> > save me huge amounts of time and limit/offset would become
> > an option.
>
> Is there a reason you can't do a count(field) query first?  If
> so, you can get the number of records returned by setting
> absolute(-1) and getting the row number.
>
> __
> David B. Held
> Software Engineer/Array Services Group
> 200 14th Ave. East,  Sartell, MN 56377
> 320.534.3637 320.253.7800 800.752.8129
--
"A power so great, it can only be used for Good or Evil!"
                -- Firesign Theatre, "The Giant Rat of Summatra"


В списке pgsql-performance по дате отправления:

Предыдущее
От: "Dave Held"
Дата:
Сообщение: Re: name search query speed
Следующее
От: John Arbash Meinel
Дата:
Сообщение: Re: name search query speed