Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Re: BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>, "Ceschia, Marcello" <Marcello(dot)Ceschia(at)medizin(dot)uni-leipzig(dot)de>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [PATCHES] Re: BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data
Date: 2008-04-03 15:00:53
Message-ID: 47F4F125.3050809@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> On second thought, expanding AttrNumber to int32, wholesale, might not 
>> be a good idea,
> 
> No, it wouldn't.  For one thing it'd be a protocol break --- column
> numbers are int16 --- 

I wasn't planning to change that.

> and for another, we'd have terrible performance
> problems with such wide rows.

Yes, we probably would :-). Though if there's any nasty O(n^2) behavior 
left in there, we should look at optimizing it anyway to speed up more 
reasonably sized queries, in the range of a few hundred columns.

>  Actually rows are supposed to be limited
> to ~1600 columns, anyway, because of HeapTupleHeader limitations.

The trick is that that limitation doesn't apply to the intermediate 
virtual tuples we move around in the executor. Those are just arrays of 
Datums, and can have more than MaxTupleAttributeNumber attributes, as 
long as you project away enough attributes, bringing it below that 
limit, before returning it to the client or materializing it into a 
HeapTuple or MinimalTuple in the executor.

> Apparently you've found a path where that restriction isn't enforced
> correctly, but I haven't seen the referenced message yet ...

Enforcing the limit for virtual tuples as well, and checking for the 
limit in the planner is one option, but it would cripple the ability to 
join extremely wide tables. For example, if you had 10 tables with 200 
columns each, you couldn't join them together even for the purposes of 
COUNT(*). Granted, that's not a very common thing to do, this is the 
first time this bug is reported after all, but I'd prefer to keep the 
capability if possible.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2008-04-03 15:18:20
Subject: Re: [PATCHES] Re: BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data
Previous:From: Tom LaneDate: 2008-04-03 14:26:53
Subject: Re: BUG #4079: libpq.dll very slow (unusable)

pgsql-patches by date

Next:From: Tom LaneDate: 2008-04-03 15:18:20
Subject: Re: [PATCHES] Re: BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data
Previous:From: Bernd HelmleDate: 2008-04-03 14:49:43
Subject: Re: psql command aliases support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group