Re: Inserts or Updates

Hi all,

We are currently "stuck" with a performance bottleneck in our server using PG and we are thinking of two potential solutions which I would be happy to hear your opinion about.

Our system has a couple of tables that hold client generated information. The clients communicate every minute with the server and thus we perform an update on these two tables every minute. We are talking about ~50K clients (and therefore records).

These constant updates have made the table sizes to grow drastically and index bloating. So the two solutions that we are talking about are:

1. Configure autovacuum to work more intensively in both time and cost parameters.
Pros:
Not a major architectural change.
Cons:
Autovacuum does not handle index bloating and thus we will need to periodically reindex the tables.
Perhaps we will also need to run vacuum full periodically if the autovacuum cleaning is not at the required pace and therefore defragmentation of the tables is needed?

1. Creating a new table every minute and inserting the data into this new temporary table (only inserts). This process will happen every minute. Note that in this process we will also need to copy missing data (clients that didn't communicate) from older table.
Pros:
Tables are always compact.
We will not reach a limit of autovacuum.
Cons:
Major architectural change.

So to sum it up, we would be happy to refrain from performing a major change to the system (solution #2), but we are not certain that the correct way to work in our situation, constant updates of records, is to configure an aggressive autovacuum or perhaps the "known methodology" is to work with temporary tables that are always inserted into?

Thank you,
Ofer

On 2/7/2012 4:18 AM, Ofer Israeli wrote:
> Hi all,
>
> We are currently “stuck” with a performance bottleneck in our server
> using PG and we are thinking of two potential solutions which I would be
> happy to hear your opinion about.
>
> Our system has a couple of tables that hold client generated
> information. The clients communicate *every* minute with the server and
> thus we perform an update on these two tables every minute. We are
> talking about ~50K clients (and therefore records).
>
> These constant updates have made the table sizes to grow drastically and
> index bloating. So the two solutions that we are talking about are:
>

You dont give any table details, so I'll have to guess. Maybe you have
too many indexes on your table? Or, you dont have a good primary index,
which means your updates are changing the primary key?

If you only have a primary index, and you are not changing it, Pg should
be able to do HOT updates.

If you have lots of indexes, you should review them, you probably don't
need half of them.

And like Kevin said, try the simple one first. Wont hurt anything, and
if it works, great!

-Andy

Hi Andy,

The two tables I am referring to have the following specs:
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

All indexes are default indexes.

The primary index is INTERGER and is not updated.

The indexes are used for sorting and filtering purposes in our UI.

I will be happy to hear your thoughts on this.

Thanks,
Ofer

-----Original Message-----
From: Andy Colson [mailto:andy(at)squeakycode(dot)net]
Sent: Tuesday, February 07, 2012 4:47 PM
To: Ofer Israeli
Cc: pgsql-performance(at)postgresql(dot)org; Olga Vingurt; Netta Kabala
Subject: Re: [PERFORM] Inserts or Updates

On 2/7/2012 4:18 AM, Ofer Israeli wrote:
> Hi all,
>
> We are currently "stuck" with a performance bottleneck in our server
> using PG and we are thinking of two potential solutions which I would be
> happy to hear your opinion about.
>
> Our system has a couple of tables that hold client generated
> information. The clients communicate *every* minute with the server and
> thus we perform an update on these two tables every minute. We are
> talking about ~50K clients (and therefore records).
>
> These constant updates have made the table sizes to grow drastically and
> index bloating. So the two solutions that we are talking about are:
>

You dont give any table details, so I'll have to guess. Maybe you have
too many indexes on your table? Or, you dont have a good primary index,
which means your updates are changing the primary key?

If you only have a primary index, and you are not changing it, Pg should
be able to do HOT updates.

If you have lots of indexes, you should review them, you probably don't
need half of them.

And like Kevin said, try the simple one first. Wont hurt anything, and
if it works, great!

-Andy

Scanned by Check Point Total Security Gateway.

> -----Original Message-----
> From: Andy Colson [mailto:andy(at)squeakycode(dot)net]
> Sent: Tuesday, February 07, 2012 4:47 PM
> To: Ofer Israeli
> Cc: pgsql-performance(at)postgresql(dot)org; Olga Vingurt; Netta Kabala
> Subject: Re: [PERFORM] Inserts or Updates
>
> On 2/7/2012 4:18 AM, Ofer Israeli wrote:
>> Hi all,
>>
>> We are currently "stuck" with a performance bottleneck in our server
>> using PG and we are thinking of two potential solutions which I would be
>> happy to hear your opinion about.
>>
>> Our system has a couple of tables that hold client generated
>> information. The clients communicate *every* minute with the server and
>> thus we perform an update on these two tables every minute. We are
>> talking about ~50K clients (and therefore records).
>>
>> These constant updates have made the table sizes to grow drastically and
>> index bloating. So the two solutions that we are talking about are:
>>
>
> You dont give any table details, so I'll have to guess. Maybe you have
> too many indexes on your table? Or, you dont have a good primary index,
> which means your updates are changing the primary key?
>
> If you only have a primary index, and you are not changing it, Pg should
> be able to do HOT updates.
>
> If you have lots of indexes, you should review them, you probably don't
> need half of them.
>
>
> And like Kevin said, try the simple one first. Wont hurt anything, and
> if it works, great!
>
> -Andy
>

On 2/7/2012 11:40 AM, Ofer Israeli wrote:
> Hi Andy,
>
> The two tables I am referring to have the following specs:
> 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
>
> All indexes are default indexes.
>
> The primary index is INTERGER and is not updated.
>
> The indexes are used for sorting and filtering purposes in our UI.
>
>
> I will be happy to hear your thoughts on this.
>
> Thanks,
> Ofer
>

Fixed that top post for ya.

Wow, so out of 46 columns, half of them have indexes? That's a lot.
I'd bet you could drop a bunch of them. You should review them and see
if they are actually helping you. You already found out that maintain
all those indexes is painful. If they are not speeding up your SELECT's
by a huge amount, you should drop them.

Sounds like you went thru your sql statements and any field that was
either in the where or order by clause you added an index for?

You need to find the columns that are the most selective. An index
should be useful at cutting the number of rows down. Once you have it
cut down, an index on another field wont really help that much. And
after a result set has been collected, an index may or may not help for
sorting.

Running some queries with EXPLAIN ANALYZE would be helpful. Give it a
run, drop an index, try it again to see if its about the same, or if
that index made a difference.

-Andy

Andy Colson <andy(at)squeakycode(dot)net> wrote:

> Wow, so out of 46 columns, half of them have indexes? That's a
> lot. I'd bet you could drop a bunch of them. You should review
> them and see if they are actually helping you. You already found
> out that maintain all those indexes is painful. If they are not
> speeding up your SELECT's by a huge amount, you should drop them.

You might want to review usage counts in pg_stat_user_indexes.

-Kevin

Oh, I knew I'd seen index usage stats someplace.

give this a run:

select * from pg_stat_user_indexes where relname = 'SuperBigTable';

http://www.postgresql.org/docs/current/static/monitoring-stats.html

-Andy

Andy Colson wrote:
> Oh, I knew I'd seen index usage stats someplace.
>
> give this a run:
>
> select * from pg_stat_user_indexes where relname = 'SuperBigTable';
>
> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>
> -Andy
>
> Scanned by Check Point Total Security Gateway.

Thanks. We have begun analyzing the indexes and indeed found many are pretty useless and will be removed.

On Wed, Feb 8, 2012 at 20:22, Ofer Israeli <oferi(at)checkpoint(dot)com> wrote:

> Andy Colson wrote:
> > Oh, I knew I'd seen index usage stats someplace.
> >
> > give this a run:
> >
> > select * from pg_stat_user_indexes where relname = 'SuperBigTable';
> >
> > http://www.postgresql.org/docs/current/static/monitoring-stats.html
> >
> > -Andy
> >
> > Scanned by Check Point Total Security Gateway.
>
>
> Thanks. We have begun analyzing the indexes and indeed found many are
> pretty useless and will be removed.
>

A quick word of warning: not all indexes are used for querying, some are
used for maintaining constraints and foreign keys. These show up as
"useless" in the above query.

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.

cheers,
Frank

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.

Thanks,
Ofer

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.

Cheers,
Frank

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!