To: jacob@aers.ca
cc: pgsql-sql@postgresql.org
Subject: Re: FW: Query length limitation in postgres server > 8.2.9 
In-reply-to: <6B5AF6293A289F45826220B17ABE7937FDB1D3@BORON.aers.local> 
References: <6B5AF6293A289F45826220B17ABE7937FDB16C@BORON.aers.local>
	<6B5AF6293A289F45826220B17ABE7937FDB1C0@BORON.aers.local>
	<3795.1247162732@sss.pgh.pa.us>
	<6B5AF6293A289F45826220B17ABE7937FDB1C6@BORON.aers.local>
	<3981.1247163226@sss.pgh.pa.us>
	<6B5AF6293A289F45826220B17ABE7937FDB1CB@BORON.aers.local>
	<4289.1247164139@sss.pgh.pa.us>
	<6B5AF6293A289F45826220B17ABE7937FDB1D3@BORON.aers.local>
Comments: In-reply-to <jacob@aers.ca>
	message dated "Thu, 09 Jul 2009 11:33:09 -0700"
Date: Thu, 09 Jul 2009 14:43:15 -0400
Message-ID: <4566.1247164995@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

<jacob@aers.ca> writes:
> the data is insert once, read many so we should be fine on that side.

It's not only the insert side where you pay for so many partial indexes.
On every query of the table, the planner is going to examine every one
of those indexes and determine whether the index is potentially usable.
Which means it attempts to prove the truth of the index WHERE clause
given the query WHERE conditions.  Most of those proof attempts are going
to fail for most queries, but not before eating a lot of planning
cycles.

On a read-mostly table, it'd probably be better to just eat the index
space needed to index the NULL entries.  They aren't going to affect
search speed noticeably for non-NULL entries, I think.

			regards, tom lane