From: Rod Taylor <pg@rbt.ca>
To: Aaron Bono <postgresql@aranya.com>
Cc: phillips@weatherbeeta.com.au
Cc: pgsql-sql@postgresql.org
Subject: Re: COPY to table with array columns (Longish)
Date: Mon, 12 Jun 2006 23:18:51 -0400
Message-ID: <1150168731.73622.10.camel@home> (raw)
In-Reply-To: <bf05e51c0606121958i54a7833bt76bb8756dd41aec1@mail.gmail.com>
References: <003901c68e7a$4833dab0$9b0014ac@ITPhil>
<14241.1150158614@sss.pgh.pa.us>
<bf05e51c0606121958i54a7833bt76bb8756dd41aec1@mail.gmail.com>
On Mon, 2006-06-12 at 21:58 -0500, Aaron Bono wrote:
> I agree with Tom. Personally I cannot think of a time I would use an
> array column over a child table. Maybe someone can enlighten me on
> when an array column would be a good choice.
Arrays are a good choice when the data comes naturally segmented.
I regularly store sentences or sentence fragments as an array of words
when I don't care about whitespace (whitespace should be regenerated on
the output). Consider meta-keywords for a webpage for example.
This is similar process as removing all formatting from phone numbers
before storage and reformatting for display to the user again.
(123)456-7890 might be stored as '1234567890'.
"A\tcat in the\nhat" might be stored as ARRAY['A', 'cat', 'in', 'the',
'hat'].
It makes comparisons and uniqueness much easier to deal with if you
remove garbage from the data prior to storage.
> On 6/12/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Phillip Smith" <phillips@weatherbeeta.com.au> writes:
> > The whole sys file is variable length records like this -
> they range =
> > from 1
> > to over 17,000 fields per record.
>
> 17000? I think you really need to rethink your schema. While
> you could
> theoretically drop 17000 elements into a PG array column, you
> wouldn't
> like the performance --- it'd be almost unsearchable for
> instance.
>
> I'd think about two tables, one with a single row for each SYS
> record
> from the original, and one with one row for each detail item
> (the
> invoice numbers in this case). With suitable indexes and a
> foreign key
> constraint, this will perform a lot better than an array-based
> translation.
>
> And no, in neither case will you be able to import that file
> without
> massaging it first.
>
> regards, tom lane
>
--
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pg@rbt.ca, postgresql@aranya.com, phillips@weatherbeeta.com.au
Subject: Re: COPY to table with array columns (Longish)
In-Reply-To: <1150168731.73622.10.camel@home>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox