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
|
Список | 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 по дате отправления: