Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function

Поиск
Список
Период
Сортировка
От Justin
Тема Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function
Дата
Msg-id 4A47A5C3.4040106@emproshunts.com
обсуждение исходный текст
Ответ на Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function  (APseudoUtopia <apseudoutopia@gmail.com>)
Ответы Re: Switching from MySQL: ON DUPLICATE KEY UPDATE, plpgsql function  (Tguru <guru@talend.com>)
Список pgsql-general
<br /><br /> APseudoUtopia wrote: <blockquote cite="mid:27ade5280906280922p2bd7ca35x549ae5993223a87a@mail.gmail.com"
type="cite"><prewrap="">thread, then logs out (intending to read all the other forum threads
 
at some point in the future when they log in again). If I used a VIEW,
it would automatically consider all those unread forum posts to be
read when the user logs out.
 </pre> That wouldn't work. What if a user logs in, reads only one forum<br /></blockquote><br /> You are keeping a
listof all the forums a user has read,  i would not worry about making sure the table tracking user activity has
duplicatekey values. The select can be limited to return just on row with the highest time stamp then compare this
resultto figure out what forms the user has not read yet.  This eliminates one of problems but creates a problem where
tabletracking user activity is going bloat but in low traffic times delete the duplicate values.<br /><br /> A similar
topicwas discussed  on the performance  mailing list, where updates are hung for several seconds for a similar tracking
table...<br/><a class="moz-txt-link-freetext"
href="http://archives.postgresql.org/pgsql-performance/2009-06/msg00300.php">http://archives.postgresql.org/pgsql-performance/2009-06/msg00300.php</a><br
/><br/>  <br /> 

В списке pgsql-general по дате отправления:

Предыдущее
От: mobiledreamers@gmail.com
Дата:
Сообщение: Re: horizontal sharding
Следующее
От: Tom Lane
Дата:
Сообщение: Re: partitioning question -- how to guarantee uniqueness across partitions