Re: How would you store read/unread topic status?

От: Chris St Denis
Тема: Re: How would you store read/unread topic status?
Дата: ,
Msg-id: 4A41D2D6.8010100@on-track.ca
(см: обсуждение, исходный текст)
Ответ на: Re: How would you store read/unread topic status?  (Mathieu Nebra)
Ответы: Re: How would you store read/unread topic status?  (Mathieu Nebra)
Список: pgsql-performance

Скрыть дерево обсуждения

How would you store read/unread topic status?  (Mathieu Nebra, )
 Re: How would you store read/unread topic status?  (Andres Freund, )
  Re: How would you store read/unread topic status?  (Mathieu Nebra, )
   Re: How would you store read/unread topic status?  (Robert Haas, )
    Re: How would you store read/unread topic status?  (Mathieu Nebra, )
     Re: How would you store read/unread topic status?  (Robert Haas, )
     Re: How would you store read/unread topic status?  (Mike, )
     Re: How would you store read/unread topic status?  (Mike, )
   Re: How would you store read/unread topic status?  (Andres Freund, )
    Re: How would you store read/unread topic status?  (Robert Haas, )
   Re: How would you store read/unread topic status?  (Scott Carey, )
    Re: How would you store read/unread topic status?  (Greg Stark, )
     Re: How would you store read/unread topic status?  (Mathieu Nebra, )
      Re: How would you store read/unread topic status?  (Craig James, )
       Re: How would you store read/unread topic status?  (Mathieu Nebra, )
      Re: How would you store read/unread topic status?  (Greg Stark, )
 Re: How would you store read/unread topic status?  (Alexander Staubo, )
  Re: How would you store read/unread topic status?  (Andres Freund, )
  Re: How would you store read/unread topic status?  (Nikolas Everett, )
   Re: How would you store read/unread topic status?  (Matthew Wakeling, )
  Re: How would you store read/unread topic status?  (Mathieu Nebra, )
   Re: How would you store read/unread topic status?  (Guillaume Cottenceau, )
   Re: How would you store read/unread topic status?  (Chris St Denis, )
    Re: How would you store read/unread topic status?  (Mathieu Nebra, )
 Re: How would you store read/unread topic status?  (justin, )
 Re: How would you store read/unread topic status?  (Grzegorz Jaśkiewicz, )
 Re: How would you store read/unread topic status?  (Scott Carey, )
 Re: How would you store read/unread topic status?  (Alexander Staubo, )

Mathieu Nebra wrote:
Alexander Staubo a écrit : 
On Tue, Jun 23, 2009 at 1:12 PM, Mathieu Nebra<> wrote:   
This "flags" table has more or less the following fields:

UserID - TopicID - LastReadAnswerID     
We are doing pretty much same thing.
   
My problem is that everytime a user READS a topic, it UPDATES this flags
table to remember he has read it. This leads to multiple updates at the
same time on the same table, and an update can take a few seconds. This
is not acceptable for my users.     
First of all, and I'm sure you thought of this, an update isn't needed
every time a user reads a topic; only when there are new answers that
need to be marked as read. So an "update ... where last_read_answer_id
< ?" should avoid the need for an update.   
We don't work that way. We just "remember" he has read these answers and
then we can tell him "there are no new messages for you to read".
So we just need to write what he has read when he reads it.
 
(That said, I believe PostgreSQL diffs tuple updates, so in practice
PostgreSQL might not be writing anything if you run an "update" with
the same value. I will let someone more intimate with the internal
details of updates to comment on this.)

Secondly, an update should not take "a few seconds". You might want to
investigate this part before you turn to further optimizations.   
Yes, I know there is a problem but I don't know if I am competent enough
to tune PostgreSQL for that. It can take a while to understand the
problem, and I'm not sure I'll have the time for that.

I am, however, opened to suggestions. Maybe I'm doing something wrong
somewhere.
 
In our application we defer the updates to a separate asynchronous
process using a simple queue mechanism, but in our case, we found that
the updates are fast enough (in the order of a few milliseconds) not
to warrant batching them into single transactions.   
A few milliseconds would be cool.
In fact, defering to another process is a good idea, but I'm not sure if
it is easy to implement. It would be great to have some sort of UPDATE
... LOW PRIORITY to make the request non blocking.

Thanks.
 
I use pg_send_query() <http://ca2.php.net/manual/en/function.pg-send-query.php> in php to achieve this for a views counter. "Script execution is not blocked while the queries are executing."

It looks like this may just be a direct translation of PQsendQuery() from libpq. Your preferred language may have a function like this.


В списке pgsql-performance по дате сообщения:

От: "Albe Laurenz"
Дата:
Сообщение: Re: Implications of having large number of users
От: Tom Lane
Дата:
Сообщение: Re: Implications of having large number of users