Re: 7.2.1 optimises very badly against 7.2 - Mailing list pgsql-general

From Sam Liddicott
Subject Re: 7.2.1 optimises very badly against 7.2
Date
Msg-id D38A0FCD5830E848992DF2D4AF5F6F4F96AA3A@conwy.leeds.ananova.internal
Whole thread Raw
In response to 7.2.1 optimises very badly against 7.2  ("Sam Liddicott" <sam.liddicott@ananova.com>)
Responses Re: 7.2.1 optimises very badly against 7.2  (Curt Sampson <cjs@cynic.net>)
List 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 by date:

Previous
From: Curt Sampson
Date:
Subject: Re: table and index size
Next
From: Steve Brett
Date:
Subject: okay so i deleted pg_log .....