public inbox for [email protected]
help / color / mirror / Atom feedRe: Recommendations on improving the insert on conflict do nothing performance
2+ messages / 2 participants
[nested] [flat]
* Re: Recommendations on improving the insert on conflict do nothing performance
@ 2024-09-12 04:35 Muhammad Usman Khan <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Muhammad Usman Khan @ 2024-09-12 04:35 UTC (permalink / raw)
To: Durgamahesh Manne <[email protected]>; +Cc: [email protected]; [email protected]
Hi,
You can use the following approaches for optimization:
- Instead of inserting one row at a time, perform bulk inserts, which
will reduce the overhead of each individual transaction
- Partitioning can improve write performance by splitting the data into
smaller, more manageable chunks
- Tune postgres configuration like
work_mem = '16MB'
shared_buffers = '8GB'
effective_cache_size = '24GB'
On Wed, 11 Sept 2024 at 13:50, Durgamahesh Manne <[email protected]>
wrote:
> Hi
> insert into
> dictionary(lang,tid,sportid,brandid,translatedtext,objecttype,basetid)
> values ($1,$2,$3,$4,$5,$6,$7) on conflict do nothing
> *8vcpus and 32gb ram
> Number of calls per sec 1600 at this time 42% of cpu utilized
> Max in ms 33.62 per call
> Avg in ms 0.17 per call
> Table
> "dictionary.dictionary"
> Column | Type | Collation | Nullable |
> Default | Storage | Compression | Stats target | Description
>
> ----------------+--------------------------+-----------+----------+----------+----------+-------------+--------------+-------------
> lang | text | | not null |
> | extended | | |
> tid | text | | not null |
> | extended | | |
> basetid | text | | not null |
> | extended | | |
> sportid | text | | |
> | extended | | |
> brandid | text | | not null |
> | extended | | |
> translatedtext | text | | |
> | extended | | |
> objecttype | text | | |
> | extended | | |
> createdat | timestamp with time zone | | not null | now()
> | plain | | |
> modified | timestamp with time zone | | not null | now()
> | plain | | |
> modifiedby | text | | not null |
> ''::text | extended | | |
> version | integer | | not null | 0
> | plain | | |
> Indexes:
> "pk_dictionary" PRIMARY KEY, btree (lang, tid)
> "idx_dictionary_basetid" btree (basetid)
> "idx_dictionary_brandid" btree (brandid)
> "idx_dictionary_objecttype" btree (objecttype)
> "idx_dictionary_sportid" btree (sportid)
> Triggers:
> i_dictionary_createdat BEFORE INSERT ON dictionary FOR EACH ROW
> EXECUTE FUNCTION update_createdat_col()
> i_dictionary_modified BEFORE INSERT OR UPDATE ON dictionary FOR EACH
> ROW EXECUTE FUNCTION update_modified_col()
> Access method: heap
> How do we improve this query performance without taking more cpu?
>
> Regards,
> Durga Mahesh
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Recommendations on improving the insert on conflict do nothing performance
@ 2024-09-12 17:03 Durgamahesh Manne <[email protected]>
parent: Muhammad Usman Khan <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Durgamahesh Manne @ 2024-09-12 17:03 UTC (permalink / raw)
To: Muhammad Usman Khan <[email protected]>; +Cc: [email protected]; [email protected]
Hi Muhammad Usman Khan
I have already set required values of params.Here issue was about
triggers.I have resolved this issue
Regards
Durga Mahesh
On Thu, Sep 12, 2024 at 10:05 AM Muhammad Usman Khan <[email protected]>
wrote:
> Hi,
> You can use the following approaches for optimization:
>
> - Instead of inserting one row at a time, perform bulk inserts, which
> will reduce the overhead of each individual transaction
> - Partitioning can improve write performance by splitting the data
> into smaller, more manageable chunks
> - Tune postgres configuration like
> work_mem = '16MB'
> shared_buffers = '8GB'
> effective_cache_size = '24GB'
>
>
> On Wed, 11 Sept 2024 at 13:50, Durgamahesh Manne <
> [email protected]> wrote:
>
>> Hi
>> insert into
>> dictionary(lang,tid,sportid,brandid,translatedtext,objecttype,basetid)
>> values ($1,$2,$3,$4,$5,$6,$7) on conflict do nothing
>> *8vcpus and 32gb ram
>> Number of calls per sec 1600 at this time 42% of cpu utilized
>> Max in ms 33.62 per call
>> Avg in ms 0.17 per call
>> Table
>> "dictionary.dictionary"
>> Column | Type | Collation | Nullable |
>> Default | Storage | Compression | Stats target | Description
>>
>> ----------------+--------------------------+-----------+----------+----------+----------+-------------+--------------+-------------
>> lang | text | | not null |
>> | extended | | |
>> tid | text | | not null |
>> | extended | | |
>> basetid | text | | not null |
>> | extended | | |
>> sportid | text | | |
>> | extended | | |
>> brandid | text | | not null |
>> | extended | | |
>> translatedtext | text | | |
>> | extended | | |
>> objecttype | text | | |
>> | extended | | |
>> createdat | timestamp with time zone | | not null | now()
>> | plain | | |
>> modified | timestamp with time zone | | not null | now()
>> | plain | | |
>> modifiedby | text | | not null |
>> ''::text | extended | | |
>> version | integer | | not null | 0
>> | plain | | |
>> Indexes:
>> "pk_dictionary" PRIMARY KEY, btree (lang, tid)
>> "idx_dictionary_basetid" btree (basetid)
>> "idx_dictionary_brandid" btree (brandid)
>> "idx_dictionary_objecttype" btree (objecttype)
>> "idx_dictionary_sportid" btree (sportid)
>> Triggers:
>> i_dictionary_createdat BEFORE INSERT ON dictionary FOR EACH ROW
>> EXECUTE FUNCTION update_createdat_col()
>> i_dictionary_modified BEFORE INSERT OR UPDATE ON dictionary FOR EACH
>> ROW EXECUTE FUNCTION update_modified_col()
>> Access method: heap
>> How do we improve this query performance without taking more cpu?
>>
>> Regards,
>> Durga Mahesh
>>
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-09-12 17:03 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-12 04:35 Re: Recommendations on improving the insert on conflict do nothing performance Muhammad Usman Khan <[email protected]>
2024-09-12 17:03 ` Durgamahesh Manne <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox