Phoenix Kiula wrote:
If you don't want to store IPs for registered users, I'd use:
user_id INTEGER,
ip cidr,
CONSTRAINT must_have_userstamp
CHECK ( user_id IS NOT NULL OR ip IS NOT NULL)
... and yes, I'd use a functional index to look it up, or even a
trigger-maintained cache of the text representation if I had to. Then
Ok, this is an idea. And I do agree that multifunction fields are a
potential pain in the distant future.
My questions:
1. What extra tax will this constraint levy on an INSERT or UPDATE on
this table? There are about 100,000 inserts a day, and over three
times as many UPDATES. The concurrency is pretty high -- I mean
sometimes 1,000 users at the same time but no more than that. If the
additional cost of insertion/updating is not too heavy, I suppose this
could be a nice approach.
2. Why not have an INET field...why a CIDR? What's the benefit? It
stores those pesky ".../8" type additional data which one has to mask
with functions. Would INET work just as well?
3. Storage wise does this add significantly? How much space does an
INET field take as opposed to, say, a VARCHAR field?
4. Most importantly, how would you structure the index for this? I
would much rather have a fast "=" in my sql's WHERE clause. No "OR"
etc. Any thoughts?
Thanks
Use the best of two worlds - consider memcached and use the db only when
you create/update an entry so that you can restore it if memcached
(perhaps as a consequence of a server reboot) gets restarted.
http://www.slideshare.net/vishnu/livejournals-backend-a-history-of-scaling
best regards,
Marcus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
