Re: 7.2.1 optimises very badly against 7.2

From: "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com>
To: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: 7.2.1 optimises very badly against 7.2
Date: 2002-07-15 10:06:27
Message-ID: D38A0FCD5830E848992DF2D4AF5F6F4F96AA3A@conwy.leeds.ananova.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> -----Original Message-----
> From: Martijn van Oosterhout [mailto:kleptog(at)svana(dot)org]
> Sent: 11 July 2002 00:37
> To: Tom Lane
> Cc: Sam Liddicott; pgsql-general(at)postgresql(dot)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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Brett 2002-07-15 10:27:44 okay so i deleted pg_log .....
Previous Message Curt Sampson 2002-07-15 07:53:14 Re: table and index size