Robert Poor <rdpoor@xxxxxxxxx> wrote:
> @kevin: I hear you. (I'm deeply steeped in Ruby on Rails and
> foolishly assume that it's easy to read.) With that in mind:
>
> \d user_associations
> id | integer | not null default
> nextval('followings_id_seq'::regclass)
I assume that this is needed to keep RoR happy. Since a row seems
meaningless without both leader_id and follower_id, and that is
unique, the synthetic key here is totally redundant. Performance
(both modifying the table and querying against it) would be faster
without this column, but I understand that many ORMs (including, as
I recall, RoR) are more difficult to work with unless you have this.
> leader_id | integer |
> follower_id | integer |
I'm surprised you didn't declare both of these as NOT NULL.
> created_at | timestamp without time zone | not null
> updated_at | timestamp without time zone | not null
I can understand tracking when the follow was initiated, but what
would you ever update here? (Or is this part of a generalized
optimistic concurrency control scheme?)
> Indexes:
> "followings_pkey" PRIMARY KEY, btree (id)
> "index_followings_on_leader_id_and_follower_id" UNIQUE, btree
> (leader_id, follower_id)
> "index_followings_on_follower_id" btree (follower_id)
> "index_followings_on_leader_id" btree (leader_id)
This last index is of dubious value when you already have an index
which starts with leader_id. It will be of even more dubious
benefit when we have index-only scans in 9.2.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
