From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | san man <neelakash21(at)gmail(dot)com> |
Cc: | Arjen Nienhuis <a(dot)g(dot)nienhuis(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: select from pipe-delimited field |
Date: | 2010-08-24 02:21:54 |
Message-ID: | 4C732CC2.6010303@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-novice |
On 08/24/2010 07:07 AM, san man wrote:
> Thanks for the replies.
> David, I would have normalized it to 2 or more tables, but the number of
> bar-delimited are not fixed and as new data are added the maximum number
> of these values may change. Also, the problem with like I think is that
> matching is not strict and thus might give spurious hits.
You are trying to simulate arrays using your own custom setup.
If you switch from using pipe-delimeted text to an array, you can use
the PostgreSQL array operators to do what you want. You even have
(limited) indexing options.
As for normalizing the data out to another table: Sometimes performance
concerns render that undesirable. Arrays can be very useful for fairly
small amounts of data that's tightly associated with a given record,
especially things like search keys.
There's a reason that tsvector is implemented how it is, rather than as
a breakout table full of keyword associations. It has to be fast, and
indexable. It sounds like the OP's problem has the same requirements.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | A.M. | 2010-08-24 03:06:44 | Re: pg_notify but no pg_listen? |
Previous Message | Craig Ringer | 2010-08-24 02:18:18 | Re: pg_notify but no pg_listen? |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-08-24 05:47:35 | Re: select from pipe-delimited field |
Previous Message | san man | 2010-08-23 23:07:08 | Re: select from pipe-delimited field |