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

From: Mathieu Nebra <mateo21(at)siteduzero(dot)com>
To: Craig James <craig_james(at)emolecules(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Scott Carey <scott(at)richrelevance(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How would you store read/unread topic status?
Date: 2009-06-24 07:42:30
Message-ID: 4A41D8E6.5020504@siteduzero.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Craig James a écrit :
> Mathieu Nebra wrote:
>> Greg Stark a écrit :
>>> All the other comments are accurate, though it does seem like
>>> something the database ought to be able to handle.
>>>
>>> The other thing which hasn't been mentioned is that you have a lot of
>>> indexes. Updates require maintaining all those indexes. Are all of
>>> these indexes really necessary? Do you have routine queries which look
>>> up users based on their flags? Or all all your oltp transactions for
>>> specific userids in which case you probably just need the index on
>>> userid.
>>
>>
>> We are using these indexes, but I can't be sure if we _really_ need them
>> or not.
>>
>> I can go into detail. We have:
>>
>> UserID - TopicID - LastReadAnswerID - WrittenStatus - IsFavorite
>>
>> So basically, we toggle the boolean flag WrittenStatus when the user has
>> written in that topic. The same goes for IsFavorite.
>
> Do those last two columns hold much data? Another thing to consider is
> to split this into two tables:

The last two columns only store TRUE or FALSE, they're booleans. So
you're saying that an index on them might be useless ? We're retrieving
1000-2000 rows max and we need to extract only those who have TRUE on
the last column for example.

>
> UserID - TopicID - LastReadAnswerID
> UserID - TopicID - WrittenStatus - IsFavorite
>
> As others have pointed out, an UPDATE in Postgres is a
> select/delete/insert, and if you're updating just the LastReadAnswerID
> all the time, you're wasting time deleting and re-inserting a lot of
> data that never change (assuming they're not trivially small columns).

They are trivially small columns.

>
> This might also solve the problem of too many indexes -- the table
> that's updated frequently would only have an index on (UserID, TopicID),
> so the update only affects one index.

I'll investigate that way.

>
> Then to minimize the impact on your app, create a view that looks like
> the original table for read-only apps.

Good idea, thanks again.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mathieu Nebra 2009-06-24 08:08:09 Re: How would you store read/unread topic status?
Previous Message Oleg Bartunov 2009-06-24 07:27:21 Re: tsvector_update_trigger performance?