Re: 7.2.1 optimises very badly against 7.2

Поиск
Список
Период
Сортировка
От Sam Liddicott
Тема Re: 7.2.1 optimises very badly against 7.2
Дата
Msg-id D38A0FCD5830E848992DF2D4AF5F6F4F96AA3A@conwy.leeds.ananova.internal
обсуждение исходный текст
Ответ на 7.2.1 optimises very badly against 7.2  ("Sam Liddicott" <sam.liddicott@ananova.com>)
Ответы Re: 7.2.1 optimises very badly against 7.2  (Curt Sampson <cjs@cynic.net>)
Список pgsql-general

> -----Original Message-----
> From: Martijn van Oosterhout [mailto:kleptog@svana.org]
> Sent: 11 July 2002 00:37
> To: Tom Lane
> Cc: Sam Liddicott; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] 7.2.1 optimises very badly against 7.2
>
> I think there is a little problem with multiple seq scans in
> a single plan.
> If your plan is only doing a single seq scan on a large
> table, then the cost
> estimate is probably fine. But if the planner chooses the seq
> scan two large
> tables in parallel, the actual disk transfers degenerate to
> random access.
> But only if they are on the same disk.
>
> Should postgres be worrying about this?

I think it should.  The same applies if two different queries are running
together of the same disk; which is probably any DB with allow_connections>1


Sam




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

Предыдущее
От: Curt Sampson
Дата:
Сообщение: Re: table and index size
Следующее
От: Steve Brett
Дата:
Сообщение: okay so i deleted pg_log .....