From: | Vivek Khera <vivek(at)khera(dot)org> |
---|---|
To: | Bill Moseley <moseley(at)hank(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance issues of one vs. two split tables. |
Date: | 2007-05-16 21:04:01 |
Message-ID: | D73AFEE3-D8CA-4F77-AC5B-A31AA52B00A9@khera.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On May 15, 2007, at 10:35 AM, Bill Moseley wrote:
>> For some value of "large", is there a time when one might consider
>> using a single column in the user or user_prefs table to represent
>> their color choices instead of a link table?
We use bitfields on our large user table. It is becoming unworkable
to scan for matches, since overall most people have very few
selections made.
We are moving it to a model like your favorite_colors table which
just links the option and the user.
We find that doing joins on large tables which can be indexed to
avoid full table scans are very fast in postgres, since the index can
do much of your culling of potential matching rows. With bitfields,
you are more or less forced into doing a sequence scan to find
everyone who likes the color red.
Of course, if you're playing with only a few thousand users, either
approach works well.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Fitzpatrick | 2007-05-16 21:33:13 | Constructing a SELECT statement in pl/pgsql |
Previous Message | Vivek Khera | 2007-05-16 20:59:24 | Re: Performance issues of one vs. two split tables. |