Re: Inserts or Updates

From: Ofer Israeli <oferi(at)checkpoint(dot)com>
To: Frank Lanitz <frank(at)frank(dot)uvena(dot)de>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Inserts or Updates
Date: 2012-02-12 18:32:11
Message-ID: 217DDBC2BB1E394CA9E7446337CBDEF20102C056C2A6@il-ex01.ad.checkpoint.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Frank Lanitz wrote:
> Am 12.02.2012 11:48, schrieb Ofer Israeli:
>> Frank Lanitz wrote:
>>>> Am 07.02.2012 18:40, schrieb Ofer Israeli:
>>>>>> Table 1: 46 columns 23 indexes on fields of the following
>>>>>> types: INTEGER - 7 TIMESTAMP - 2 VARCHAR - 12 UUID - 2
>>>>>>
>>>>>> 23 columns 12 indexes on fields of the following types:
>>>>>> INTEGER - 3 TIMESTAMP - 1 VARCHAR - 6 UUID - 2
>>>>
>>>> Are you regularly updating all columns? If not, maybe a good idea
>>>> to split the tables so highly updated columns don't effect complete
>>>> line.
>> We're not always updating all of the columns, but the reason for
>> consolidating all the columns into one table is for UI purposes - in
>> the past, they had done benchmarks and found the JOINs to be
>> extremely slow and so all data was consolidated into one table.
>
> Ah... I see. Maybe you can check whether all of the data are really
> needed to fetch with one select but this might end up in tooo much
> guessing and based on your feedback you already did this step.

This was indeed checked, but I'm not sure it was thorough enough so we're having a go at it again. In the meanwhile, the autovacuum configurations have proved to help us immensely so for now we're good (will probably be asking around soon when we hit our next bottleneck :)). Thanks for your help!

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2012-02-12 19:49:33 Re: random_page_cost = 2.0 on Heroku Postgres
Previous Message Frank Lanitz 2012-02-12 18:29:13 Re: Inserts or Updates