On 6 Jan 2012, at 22:56, Lee Hachadoorian wrote:
> What I am working with is called the summary file, which presents the data in
> aggregate. That means you have an income table with 16 income classes, plus a
> total column.
That could be a table: income class and income.
It may make sense to
On Thu, Jan 5, 2012 at 10:19 PM, Darren Duncan
wrote:
>
> This all being said, 23K values per row just sounds wrong, and I can't
> imagine any census forms having that many details.
>
> Do you, by chance, have multiple values of the same type that are in
> different fields, eg telephone_1, telep
Lee Hachadoorian wrote:
On 01/05/2012 06:18 PM, Tom Lane wrote:
Are there really 23000 populated values in each row? I hesitate to
suggest an EAV approach, but it kinda seems like you need to go in that
direction. You're never going to get decent performance out of a schema
that requires 100-w
On Thu, Jan 5, 2012 at 6:10 PM, Lee Hachadoorian
wrote:
>
> Many of the smaller geographies, e.g. census tracts, do in fact have data
> for the vast majority of the columns. I am trying to combine it all into one
> table to avoid the slowness of multiple JOINs (even though in practice I'm
> never
On 01/05/2012 06:18 PM, Tom Lane wrote:
ERROR: joins can have at most 32767 columns
It's the sum of the number of columns in the base tables.
That makes sense. I totally misunderstood the message to be referring to
the number of joined columns rather than table columns.
I've asked this li
Lee Hachadoorian writes:
> How is the number of columns in a join determined? When I combine somewhere
> around 90 tables in a JOIN, the query returns:
> ERROR: joins can have at most 32767 columns
It's the sum of the number of columns in the base tables.
> I'm sure most people will say "Why th
