Re: Inserts or Updates - Mailing list pgsql-performance

From Ofer Israeli
Subject Re: Inserts or Updates
Date
Msg-id 217DDBC2BB1E394CA9E7446337CBDEF20102C056C2A6@il-ex01.ad.checkpoint.com
Whole thread Raw
In response to Re: Inserts or Updates  (Frank Lanitz <frank@frank.uvena.de>)
List 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,
theautovacuum configurations have proved to help us immensely so for now we're good (will probably be asking around
soonwhen we hit our next bottleneck :)).  Thanks for your help! 

pgsql-performance by date:

Previous
From: Frank Lanitz
Date:
Subject: Re: Inserts or Updates
Next
From: Jeff Janes
Date:
Subject: Re: random_page_cost = 2.0 on Heroku Postgres