Re: [HACKERS] Solution for LIMIT cost estimation

Поиск
Список
Период
Сортировка
От Chris Bitmead
Тема Re: [HACKERS] Solution for LIMIT cost estimation
Дата
Msg-id 38A89009.4DE7A872@nimrod.itg.telecom.com.au
обсуждение исходный текст
Ответ на Solution for LIMIT cost estimation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Don Baccus wrote:
> 
> At 10:47 PM 2/14/00 +1100, Chris wrote:
> 
> >Only that it's non intuitive that ORDER BY should change the actual
> >results of a series of LIMIT queries, not just the order. If there are
> >100 records, and I do 10x LIMIT 10,offset queries one might expect to
> >get all 100 records.
> 
> The only person who will expect that is the person who hasn't bothered
> to learn the fundamental SQL property that rows returned by queries
> come back in non-deterministic order.
> 
> This is a FUNDAMENTAL concept in SQL, one that is mentioned in every
> SQL book I've seen.

It's a logical fact that the existance of "offset", automatically
implies
ordering, no matter how many SQL textbooks you quote.

> It will only give consistent results if the table doesn't
>change, which is only likely to be during testing if the 
>table is one which is inserted into, updated, and the like
>during production, such as is true of bulletin boards and
>the like.

It's actually very typical for web applications to want to search
through
historical stuff that doesn't change any more. And ordering by title
or something might not be good enough.

IMHO, that's a better reasoning that wanting to misuse LIMIT to figure
out if there are duplicates or something, just because nobody can
be bothered optimising the correct SQL to do that.


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Release on the 15th?
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] Solution for LIMIT cost estimation