Re: Bulk Update

Merhabalar,

Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5
milyonluk bir kayıt. Oracle’da begin end’in arasına commit koyabiliyorduk.
Fakat Postgresql’de bunu yapamadığımızı farkına vardık. 100 kayıt update
ettikten sonra commit yapmak istiyoruz. Bu gibi ihtiyaçlar için
Postgresql’de nasıl bir çözüm kullanıyorsunuz?

İyi çalışmalar.

Örnek kod:

*DECLARE **c_delivery **RECORD*
*; cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id **BIGINT**)
FOR SELECT ****
* FROM *
*receiver_address*
* WHERE *
*receiver_id** = **x_receiver_id*
*
AND
**address_id** = **x_address_id*
*; **c_rad **RECORD*

*;BEGIN FOR **c_delivery** IN SELECT ***** FROM **delivery** WHERE
recipient_address_id is NULL LIMIT **p_record_cnt*

* LOOP OPEN cur_rad(**c_delivery**.**receiver_address_id**,**c_delivery*
*.**receiver_id*
*); FETCH cur_rad INTO **c_rad*
*; IF **c_rad*

*.id IS NOT NULL THEN UPDATE *********** SET recipient_address_id =
**c_rad**.id WHERE **id** = **c_delivery**.**id*
*; UPDATE **************** SET recipient_address_id = **c_rad**.id
WHERE **delivery_id** = **c_delivery**.**id*

*; END IF; CLOSE cur_rad; END LOOP;END;*

*FIRAT GÜLEÇ*
Veritabanı Yöneticisi
firat(dot)gulec(at)hepsiexpress(dot)com

*M:* 0 532 210 57 18
İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
------------------------------

[image: Inline image 1]

Hocam fonksiyon içinden transaction başlatıp sonlandıramıyorsunuz.
Fonksiyon ile bunu yapamazsınız.
p_record_cnt değişkeni ile limit değeri belirlediğinize göre fonksiyonu
uygulama tarafında total count / limit değeri kadar döngüleyerek
çağırıyorsunuz ve bunu yapmak yerine tüm işlemi aynı döngü içinde yapmak
istiyorsunuz.
Doğru mu?

29 Eylül 2017 10:03 tarihinde Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>
yazdı:

> Merhabalar,
>
>
>
> Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
> kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5
> milyonluk bir kayıt. Oracle’da begin end’in arasına commit koyabiliyorduk.
> Fakat Postgresql’de bunu yapamadığımızı farkına vardık. 100 kayıt update
> ettikten sonra commit yapmak istiyoruz. Bu gibi ihtiyaçlar için
> Postgresql’de nasıl bir çözüm kullanıyorsunuz?
>
>
>
> İyi çalışmalar.
>
>
>
>
>
> Örnek kod:
>
>
> *DECLARE **c_delivery **RECORD*
> *; cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id **BIGINT**)
> FOR SELECT ****
> * FROM *
> *receiver_address*
> * WHERE *
> *receiver_id** = **x_receiver_id*
> *
> AND
> **address_id** = **x_address_id*
> *; **c_rad **RECORD*
>
> *;BEGIN FOR **c_delivery** IN SELECT ***** FROM **delivery** WHERE
> recipient_address_id is NULL LIMIT **p_record_cnt*
>
> * LOOP OPEN cur_rad(**c_delivery**.**receiver_address_id**,*
> *c_delivery**.**receiver_id*
> *); FETCH cur_rad INTO **c_rad*
> *; IF **c_rad*
>
> *.id IS NOT NULL THEN UPDATE *********** SET recipient_address_id
> = **c_rad**.id WHERE **id** = **c_delivery**.**id*
> *; UPDATE **************** SET recipient_address_id = **c_rad**.id
> WHERE **delivery_id** = **c_delivery**.**id*
>
>
>
> *; END IF; CLOSE cur_rad; END LOOP;END;*
>
>
>
>
>
> *FIRAT GÜLEÇ*
> Veritabanı Yöneticisi
> firat(dot)gulec(at)hepsiexpress(dot)com
>
>
>
> *M:* 0 532 210 57 18
> İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
> ------------------------------
>
> [image: Inline image 1]
>
>
>

Merhabalar,

Bu gibi ihtiyaçlar geliştiğinde aşağıdaki gibi tek bir UPDATE ifadesi
çalıştırıyorum.

> *UPDATE* "tablo_1" *AS* t1
>
> *SET* "alan_1" *=* t2*.*"alan_1"
> *,*"alan_2" *=* t2*.*"alan_2"
>
> *FROM* "tablo_2" *AS* t2
>
> *WHERE* t1*.*"id" *=* t2*.*"ref_id"
> *;*

İyi çalışmalar.

*N. Can KIRIKePati Bilişim Teknolojilerihttp://www.epati.com.tr/
<http://www.epati.com.tr/>*

2017-09-29 10:03 GMT+03:00 Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>:

> Merhabalar,
>
>
>
> Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
> kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5
> milyonluk bir kayıt. Oracle’da begin end’in arasına commit koyabiliyorduk.
> Fakat Postgresql’de bunu yapamadığımızı farkına vardık. 100 kayıt update
> ettikten sonra commit yapmak istiyoruz. Bu gibi ihtiyaçlar için
> Postgresql’de nasıl bir çözüm kullanıyorsunuz?
>
>
>
> İyi çalışmalar.
>
>
>
>
>
> Örnek kod:
>
>
> *DECLARE **c_delivery **RECORD*
> *; cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id **BIGINT**)
> FOR SELECT ****
> * FROM *
> *receiver_address*
> * WHERE *
> *receiver_id** = **x_receiver_id*
> *
> AND
> **address_id** = **x_address_id*
> *; **c_rad **RECORD*
>
> *;BEGIN FOR **c_delivery** IN SELECT ***** FROM **delivery** WHERE
> recipient_address_id is NULL LIMIT **p_record_cnt*
>
> * LOOP OPEN cur_rad(**c_delivery**.**receiver_address_id**,*
> *c_delivery**.**receiver_id*
> *); FETCH cur_rad INTO **c_rad*
> *; IF **c_rad*
>
> *.id IS NOT NULL THEN UPDATE *********** SET recipient_address_id
> = **c_rad**.id WHERE **id** = **c_delivery**.**id*
> *; UPDATE **************** SET recipient_address_id = **c_rad**.id
> WHERE **delivery_id** = **c_delivery**.**id*
>
>
>
> *; END IF; CLOSE cur_rad; END LOOP;END;*
>
>
>
>
>
> *FIRAT GÜLEÇ*
> Veritabanı Yöneticisi
> firat(dot)gulec(at)hepsiexpress(dot)com
>
>
>
> *M:* 0 532 210 57 18 <0532%20210%2057%2018>
> İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
> ------------------------------
>
> [image: Inline image 1]
>
>
>

Eğer |COMMIT|etmez iseniz ORACLE'da |ORA-1562 FAILED TO EXTEND ROLLBACK
SEGMENT|hatası alırsınız. Fakat PostgreSQL'in işleyişi biraz farklı,
rollback segment yok, o yüzden de extend edilmesi gereken birproblem de
olmuyor (Onun yerine |VACUUM|işlemlerimiz kalıyor sonrası için :-)).
Şunu okuyunuz:

It is interesting how the dynamic allocation of disk space is used
for the storage and processing of records within tables. The files
that represent the table grow as the table grows. It also grows with
transactions that are performed against it. In Oracle there is a
concept of rollback or undo segments that hold the information for
rolling back a transaction. In PostgreSQL the data is stored within
the file that represents the table. So when deletes and updates are
performed on a table, the file that represents the object will
contain the previous data. This space gets reused but to force
recovery of used space, a maintenance process called /vacuum/must be
executed.

Onun için bulk update'i tek SQL ile yapabilirsiniz. Ama yine de
|COMMIT|'i transaction içinde yapmanız gerekiyorsa, cursor'u |WITH
HOLD|ile tanımlayınız
</docs/current/static/sql-declare.html>.

|WITH HOLD|specifies that the cursor can continue to be used after
the transaction that created it successfully commits. |WITHOUT
HOLD|specifies that the cursor cannot be used outside of the
transaction that created it. If neither |WITHOUT HOLD|nor |WITH
HOLD|is specified, |WITHOUT HOLD|is the default.

On 29-09-2017 10:03, Fırat Güleç wrote:
>
> Merhabalar,
>
> Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
> kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5
> milyonluk bir kayıt. Oracle’da begin end’in arasına commit
> koyabiliyorduk. Fakat Postgresql’de bunu yapamadığımızı farkına
> vardık. 100 kayıt update ettikten sonra commit yapmak istiyoruz. Bu
> gibi ihtiyaçlar için Postgresql’de nasıl bir çözüm kullanıyorsunuz?
>
> İyi çalışmalar.
>
> Örnek kod:
>
> *DECLARE
> **c_delivery **RECORD**;
>     cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id
> **BIGINT**) FOR SELECT */*/*
>                         FROM **receiver_address**
>                                                                   
> WHERE **receiver_id**= **x_receiver_id**AND
> **address_id**= **x_address_id**;
> **c_rad **RECORD**;
> BEGIN
>   FOR **c_delivery**IN SELECT */*/*FROM **delivery**WHERE
> recipient_address_id is NULL LIMIT **p_record_cnt**LOOP
>
>     OPEN
> cur_rad(**c_delivery**.**receiver_address_id**,**c_delivery**.**receiver_id**);
>     FETCH cur_rad INTO **c_rad**;
>     IF **c_rad**.id IS NOT NULL
>     THEN
>       UPDATE ***********SET recipient_address_id = **c_rad**.id WHERE
> **id**= **c_delivery**.**id**;
>       UPDATE ****************SET recipient_address_id = **c_rad**.id
> WHERE **delivery_id**= **c_delivery**.**id**;
>     END IF;
>     CLOSE cur_rad;
>   END LOOP;
> END;*
>
> *FIRAT GÜLEÇ***
> Veritabanı Yöneticisi
> firat(dot)gulec(at)hepsiexpress(dot)com <mailto:firat(dot)gulec(at)hepsiexpress(dot)com>
>
> *M:*0 532 210 57 18
> İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
>
> ------------------------------------------------------------------------
>
> Inline image 1
>

Merhabalar,

Dönüşleriniz için çok teşekkür ederim.

Bundan beş ay önce bir çalışanımızın haber vermeden yaptığı tek satırlık
update (Yaklaşık 5 milyon kayıt) tamamlanmadan, database diğer requestlere
cevap veremez hale geldi. O zamanlar PL/SQL’de yeni olduğumdan dolayı
update cümleciklerinin arasına commit koymadığından dolayı bu problem
yaşadığımızı düşünmüştüm. O yüzden aynı duruma düşmemek için bu kadar
kayıt’ın update’ini bir sql’de yapmak istemiyorum.

@M.Atıf CEYLAN, evet tam olarak istediğim bu, bütün update’i problem
yaşamadan 100 kayıtta bir veya her kayıttan sonra da olabilir, commit
yapmış gibi, dışarıya görünür kılmak istiyorum. Bulk update’den dolayı
temp, memory veya file’in şişmesini istemiyorum.

@N. Can KIRIK, yukarıda belirttiğim gibi daha önceki tecrübemden dolayı tek
sql kullanmaya sıcak bakmıyorum.

@Erkan Durmuş , tam anlayamadığım bir nokta var, cursor’i with hold ile
tanımladığımız zaman, her bir transaction’dan sonra mı commit koyuyor. Yani
3 milyon tane kayıt update edicek isek, 3 milyon commit mi demek?

İyi çalışmalar.

*From:* pgsql-tr-genel-owner(at)postgresql(dot)org [mailto:
pgsql-tr-genel-owner(at)postgresql(dot)org] *On Behalf Of *Erkan Durmus
*Sent:* Saturday, September 30, 2017 10:39 AM
*To:* pgsql-tr-genel(at)postgresql(dot)org
*Subject:* Re: [pgsql-tr-genel] Bulk Update

Eğer COMMIT etmez iseniz ORACLE'da ORA-1562 FAILED TO EXTEND ROLLBACK
SEGMENT hatası alırsınız. Fakat PostgreSQL'in işleyişi biraz farklı,
rollback segment yok, o yüzden de extend edilmesi gereken birproblem de
olmuyor (Onun yerine VACUUM işlemlerimiz kalıyor sonrası için :-)). Şunu
okuyunuz:

It is interesting how the dynamic allocation of disk space is used for the
storage and processing of records within tables. The files that represent
the table grow as the table grows. It also grows with transactions that are
performed against it. In Oracle there is a concept of rollback or undo
segments that hold the information for rolling back a transaction. In
PostgreSQL the data is stored within the file that represents the table. So
when deletes and updates are performed on a table, the file that represents
the object will contain the previous data. This space gets reused but to
force recovery of used space, a maintenance process called *vacuum* must be
executed.

Onun için bulk update'i tek SQL ile yapabilirsiniz. Ama yine de COMMIT'i
transaction içinde yapmanız gerekiyorsa, cursor'u WITH HOLD ile tanımlayınız
</docs/current/static/sql-declare.html>.

WITH HOLD specifies that the cursor can continue to be used after the
transaction that created it successfully commits. WITHOUT HOLD specifies
that the cursor cannot be used outside of the transaction that created it.
If neither WITHOUT HOLD nor WITH HOLD is specified, WITHOUT HOLD is the
default.

On 29-09-2017 10:03, Fırat Güleç wrote:

Merhabalar,

Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5
milyonluk bir kayıt. Oracle’da begin end’in arasına commit koyabiliyorduk.
Fakat Postgresql’de bunu yapamadığımızı farkına vardık. 100 kayıt update
ettikten sonra commit yapmak istiyoruz. Bu gibi ihtiyaçlar için
Postgresql’de nasıl bir çözüm kullanıyorsunuz?

İyi çalışmalar.

Örnek kod:

*DECLARE **c_delivery **RECORD*
*; cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id **BIGINT**)
FOR SELECT ****
* FROM *
*receiver_address*
* WHERE *
*receiver_id** = **x_receiver_id*
*
AND
**address_id** = **x_address_id*
*; **c_rad **RECORD*

*;BEGIN FOR **c_delivery** IN SELECT ***** FROM **delivery** WHERE
recipient_address_id is NULL LIMIT **p_record_cnt*

* LOOP OPEN cur_rad(**c_delivery**.**receiver_address_id**,**c_delivery*
*.**receiver_id*
*); FETCH cur_rad INTO **c_rad*
*; IF **c_rad*

*.id IS NOT NULL THEN UPDATE *********** SET recipient_address_id =
**c_rad**.id WHERE **id** = **c_delivery**.**id*
*; UPDATE **************** SET recipient_address_id = **c_rad**.id
WHERE **delivery_id** = **c_delivery**.**id*

*; END IF; CLOSE cur_rad; END LOOP;END;*

*FIRAT GÜLEÇ*
Veritabanı Yöneticisi
firat(dot)gulec(at)hepsiexpress(dot)com

*M:* 0 532 210 57 18
İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
------------------------------

[image: Inline image 1]

Selamlar Fırat,

Bu gereksinim için dblink'i kullanabilirsin. dblink ile çalıştırdığın sorgu mevcut transaction'dan bağımsız olarak hedef veritabanında çalışacaktır. Aşağıdaki dblink_exec bölümünü döngünün içerisine koyarak döngü içerisinde transaction açıp update yapabilir, istediğin sıklıkta transaction'ı commit edebilirsin.

Eklentiyi yaratmak için:

create extension dblink;

Eklentiyi oluşturduktan sonra transaction içerisinde aşağıdaki gibi kullanabilirsin.

begin;

--dblink ile veritabanına bağlan

select dblink_connect('dbname=firat');

--transaction'ı başlat


select dblink_exec('begin;');

-- sorguyu çalıştır

select dblink_exec('update bulk_update set c1=10 where id =50000;');

--transaction'ı commit et


select dblink_exec('commit;');

-- dblink bağlantısını sonlandır

select dblink_disconnect();

commit;

İyi çalışmalar.

Samed YILDIRIM

29.09.2017, 10:03, "Fırat Güleç" firat(dot)gulec(at)hepsiexpress(dot)com:

Merhabalar,

Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık 4.5 milyonluk bir kayıt. Oracle’da begin end’in arasına commit koyabiliyorduk. Fakat Postgresql’de bunu yapamadığımızı farkına vardık. 100 kayıt update ettikten sonra commit yapmak istiyoruz. Bu gibi ihtiyaçlar için Postgresql’de nasıl bir çözüm kullanıyorsunuz?

İyi çalışmalar.

Örnek kod:

DECLARE

c_delivery RECORD;

cur_rad CURSOR (x_address_id BIGINT, x_receiver_id BIGINT) FOR SELECT *

FROM receiver_address

WHERE receiver_id = x_receiver_id AND

address_id = x_address_id;

c_rad RECORD;

BEGIN

FOR c_delivery IN SELECT * FROM delivery WHERE recipient_address_id is NULL LIMIT p_record_cnt LOOP

OPEN cur_rad(c_delivery.receiver_address_id,c_delivery.receiver_id);

FETCH cur_rad INTO c_rad;

IF c_rad.id IS NOT NULL

THEN

UPDATE ******* SET recipient_address_id = c_rad.id WHERE id = c_delivery.id;

UPDATE ************ SET recipient_address_id = c_rad.id WHERE delivery_id = c_delivery.id;

END IF;

CLOSE cur_rad;

END LOOP;

END;

FIRAT GÜLEÇ

Veritabanı Yöneticisi

firat(dot)gulec(at)hepsiexpress(dot)com

M:0 532 210 57 18

İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ

|WITHOUT HOLD|ile açılan cursor'ü sadece SQL komut satırında
kullanabiliyormuşuz, bu durumda PL/pgSQL içinde bu seçenek geçersiz
</docs/9.1/static/sql-declare.html>.

*Note:*This page describes usage of cursors at the SQL command
level. If you are trying to use cursors inside a PL/pgSQL function,
the rules are different

Onun yerine ya tek SQL ile yapacaksınız veya extension üzerinden,
örneğin pg_background
<https://github.com/vibhorkum/pg_background>kullanabilirsiniz. Örnek
kullanım için bu yazıya
<http://blog.dalibo.com/2016/08/19/Autonoumous_transactions_support_in_PostgreSQL.html>bakabilirsiniz.

On 30-09-2017 15:31, Fırat Güleç wrote:
>
> Merhabalar,
>
> Dönüşleriniz için çok teşekkür ederim.
>
> Bundan beş ay önce bir çalışanımızın haber vermeden yaptığı tek
> satırlık update (Yaklaşık 5 milyon kayıt) tamamlanmadan, database
> diğer requestlere cevap veremez hale geldi. O zamanlar PL/SQL’de yeni
> olduğumdan dolayı update cümleciklerinin arasına commit koymadığından
> dolayı bu problem yaşadığımızı düşünmüştüm. O yüzden aynı duruma
> düşmemek için bu kadar kayıt’ın update’ini bir sql’de yapmak istemiyorum.
>
> @M.Atıf CEYLAN, evet tam olarak istediğim bu, bütün update’i problem
> yaşamadan 100 kayıtta bir veya her kayıttan sonra da olabilir, commit
> yapmış gibi, dışarıya görünür kılmak istiyorum. Bulk update’den dolayı
> temp, memory veya file’in şişmesini istemiyorum.
>
> @N. Can KIRIK, yukarıda belirttiğim gibi daha önceki tecrübemden
> dolayı tek sql kullanmaya sıcak bakmıyorum.
>
> @Erkan Durmuş , tam anlayamadığım bir nokta var, cursor’i with hold
> ile tanımladığımız zaman, her bir transaction’dan sonra mı commit
> koyuyor. Yani 3 milyon tane kayıt update edicek isek, 3 milyon commit
> mi demek?
>
> İyi çalışmalar.
>
> *From:*pgsql-tr-genel-owner(at)postgresql(dot)org
> <mailto:pgsql-tr-genel-owner(at)postgresql(dot)org>
> [mailto:pgsql-tr-genel-owner(at)postgresql(dot)org
> <mailto:pgsql-tr-genel-owner(at)postgresql(dot)org>] *On Behalf Of *Erkan Durmus
> *Sent:* Saturday, September 30, 2017 10:39 AM
> *To:* pgsql-tr-genel(at)postgresql(dot)org <mailto:pgsql-tr-genel(at)postgresql(dot)org>
> *Subject:* Re: [pgsql-tr-genel] Bulk Update
>
> Eğer |COMMIT|etmez iseniz ORACLE'da |ORA-1562 FAILED TO EXTEND
> ROLLBACK SEGMENT|hatası alırsınız. Fakat PostgreSQL'in işleyişi biraz
> farklı, rollback segment yok, o yüzden de extend edilmesi gereken
> birproblem de olmuyor (Onun yerine |VACUUM|işlemlerimiz kalıyor
> sonrası için :-)). Şunu okuyunuz:
>
> It is interesting how the dynamic allocation of disk space is used
> for the storage and processing of records within tables. The files
> that represent the table grow as the table grows. It also grows
> with transactions that are performed against it. In Oracle there
> is a concept of rollback or undo segments that hold the
> information for rolling back a transaction. In PostgreSQL the data
> is stored within the file that represents the table. So when
> deletes and updates are performed on a table, the file that
> represents the object will contain the previous data. This space
> gets reused but to force recovery of used space, a maintenance
> process called /vacuum/must be executed.
>
> Onun için bulk update'i tek SQL ile yapabilirsiniz. Ama yine de
> |COMMIT|'i transaction içinde yapmanız gerekiyorsa, cursor'u |WITH
> HOLD|ile tanımlayınız
> </docs/current/static/sql-declare.html>.
>
> |WITH HOLD|specifies that the cursor can continue to be used after
> the transaction that created it successfully commits. |WITHOUT
> HOLD|specifies that the cursor cannot be used outside of the
> transaction that created it. If neither |WITHOUT HOLD|nor |WITH
> HOLD|is specified, |WITHOUT HOLD|is the default.
>
> On 29-09-2017 10:03, Fırat Güleç wrote:
>
> Merhabalar,
>
> Bir konuda yardımınız ihtiyacım var. Postgresql 9.5.8 versiyonunu
> kullanıyoruz. Bulk bir update yapmaya ihtiyacımız oldu, yaklaşık
> 4.5 milyonluk bir kayıt. Oracle’da begin end’in arasına commit
> koyabiliyorduk. Fakat Postgresql’de bunu yapamadığımızı farkına
> vardık. 100 kayıt update ettikten sonra commit yapmak istiyoruz.
> Bu gibi ihtiyaçlar için Postgresql’de nasıl bir çözüm
> kullanıyorsunuz?
>
> İyi çalışmalar.
>
> Örnek kod:
>
> *DECLARE
> **c_delivery **RECORD**;
>     cur_rad CURSOR (**x_address_id **BIGINT**, **x_receiver_id
> **BIGINT**) FOR SELECT */*/*
>                         FROM **receiver_address**
>                                                                   
> WHERE **receiver_id**= **x_receiver_id**AND
> **address_id**= **x_address_id**;
> **c_rad **RECORD**;
> BEGIN
>   FOR **c_delivery**IN SELECT */*/*FROM **delivery**WHERE
> recipient_address_id is NULL LIMIT **p_record_cnt**LOOP
>
>     OPEN
> cur_rad(**c_delivery**.**receiver_address_id**,**c_delivery**.**receiver_id**);
>     FETCH cur_rad INTO **c_rad**;
>     IF **c_rad**.id IS NOT NULL
>     THEN
>       UPDATE ***********SET recipient_address_id = **c_rad**.id
> WHERE **id**= **c_delivery**.**id**;
>       UPDATE ****************SET recipient_address_id =
> **c_rad**.id WHERE **delivery_id**= **c_delivery**.**id**;
>     END IF;
>     CLOSE cur_rad;
>   END LOOP;
> END;*
>
> *FIRAT GÜLEÇ***
> Veritabanı Yöneticisi
> firat(dot)gulec(at)hepsiexpress(dot)com <mailto:firat(dot)gulec(at)hepsiexpress(dot)com>
>
> *M:*0 532 210 57 18
> İnönü Mh. Mimar Sinan Cd. No:3 Güzeller Org.San.Bölg. GEBZE / KOCAELİ
>
> ------------------------------------------------------------------------
>
> Inline image 1
>

Merhabalar,

On Sat, 2017-09-30 at 15:31 +0300, Fırat Güleç wrote:
> Bundan beş ay önce bir çalışanımızın haber vermeden yaptığı tek satırlık
> update (Yaklaşık 5 milyon kayıt) tamamlanmadan, database diğer requestlere
> cevap veremez hale geldi.

Ben iletileri tam okuyamadım daha ama, burası dikkatimi çekti: 5 milyon kaydı
etkileyen bir update işleminden sunucu yanıt veremez hale geliyorsa, bence
sunucuya bakmak gerekli, kırk takla atarak çözüm getirmek yerine yani.

Bu hafta İsveç'de bir müşterideydim, 1.6 TB'lık DWH'lerinde 3.5 milyon satırlık
select/insert/update karışımı bir sorgu birkaç dakikada bitti (-ki yavaşlık
var, sorunu çözüyoruz).

İyi çalışmalar,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

sanıyorum 5 milyon kaydı etkileyen update sürerken, diğer bağlantılardan da
gelen update işlemleri
nedeniyle exclusive lock söz konusu oluyor ve bu yüzden cevap veremez
duruma düşüyor.

deneme yapmak için verilerin bir kopyasını başka bir sunucuya taşıyıp,
başka bağlantı yokken
update performasına bakmak, ardından da pg_tune ile ayarları optimize edip
performansı karşılaştırmak
basit bir çözüme götürebilir.

bu çok yapılan bir update işlemi ise bu update'e ihtiyaç doğuran problemi
farklı şekilde çözmek gerekebilir.

iyi çalışmalar.

*N. Can KIRIKePati Bilişim Teknolojilerihttp://www.epati.com.tr/
<http://www.epati.com.tr/>*

2017-10-01 5:43 GMT+03:00 Devrim Gündüz <devrim(at)gunduz(dot)org>:

>
> Merhabalar,
>
> On Sat, 2017-09-30 at 15:31 +0300, Fırat Güleç wrote:
> > Bundan beş ay önce bir çalışanımızın haber vermeden yaptığı tek satırlık
> > update (Yaklaşık 5 milyon kayıt) tamamlanmadan, database diğer
> requestlere
> > cevap veremez hale geldi.
>
> Ben iletileri tam okuyamadım daha ama, burası dikkatimi çekti: 5 milyon
> kaydı
> etkileyen bir update işleminden sunucu yanıt veremez hale geliyorsa, bence
> sunucuya bakmak gerekli, kırk takla atarak çözüm getirmek yerine yani.
>
> Bu hafta İsveç'de bir müşterideydim, 1.6 TB'lık DWH'lerinde 3.5 milyon
> satırlık
> select/insert/update karışımı bir sorgu birkaç dakikada bitti (-ki yavaşlık
> var, sorunu çözüyoruz).
>
> İyi çalışmalar,
> --
> Devrim Gündüz
> EnterpriseDB: https://www.enterprisedb.com
> PostgreSQL Consultant, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>

Merhabalar,

On Sun, 2017-10-01 at 19:11 +0300, N. Can KIRIK wrote:
> sanıyorum 5 milyon kaydı etkileyen update sürerken, diğer bağlantılardan da
> gelen update işlemleri nedeniyle exclusive lock söz konusu oluyor ve bu
> yüzden cevap veremez duruma düşüyor.

Öyleyse de yazılım sorunu, aynı anda 5 milyon kayıdı birden fazla neden update
etsinler ki? Fırat Bey açıklar herhalde.

Zaten ya dediğin gibi hocam, ya da donanım/tuning sorunu var.

Saygılar,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Merhaba,

Cevap veremez duruma düşüyor derken o tabloları kullanan sorgular için bunu
söylemedim. Bütün db gelen sorgularda problem yaşamıştık, loginler vs bile
gelmez olmuştu. Bu yüzden lock'dan dolayı olduğunu düşünmüyorum.

Test ortamında bu update'i denedim. Yaklaşık 5 dak da 4.5 milyon kaydı
update ettim, bir problem yaşamadım, fakat cpu tavan yaptı. Canlıda böyle
bir update yapacak isem gece saatlerinde yapmayı öngörüyorum. Server'ın
donanımını ve tuning konularını biraz daha inceleyeceğm.

Yardımlarınız için hepinize teşekkür ederim.

-----Original Message-----
From: Devrim Gündüz [mailto:devrim(at)gunduz(dot)org]
Sent: Sunday, October 1, 2017 10:38 PM
To: N. Can KIRIK <can(at)epati(dot)com(dot)tr>
Cc: Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>; Erkan Durmuş
<derkan(at)gmail(dot)com>; M.Atıf CEYLAN <mehmet(at)atifceylan(dot)com>; pgsql-tr-genel
<pgsql-tr-genel(at)postgresql(dot)org>
Subject: Re: [pgsql-tr-genel] Bulk Update

Merhabalar,

On Sun, 2017-10-01 at 19:11 +0300, N. Can KIRIK wrote:
> sanıyorum 5 milyon kaydı etkileyen update sürerken, diğer
> bağlantılardan da gelen update işlemleri nedeniyle exclusive lock söz
> konusu oluyor ve bu yüzden cevap veremez duruma düşüyor.

Öyleyse de yazılım sorunu, aynı anda 5 milyon kayıdı birden fazla neden
update etsinler ki? Fırat Bey açıklar herhalde.

Zaten ya dediğin gibi hocam, ya da donanım/tuning sorunu var.

Saygılar,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com PostgreSQL Consultant, Red Hat
Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

4.5 milyon update icin 5dk çok uzun süre. Muhtemelen bunun nedeni loop ile
ve 100 satir 100 satir bu islemi yamaniz.

Update from seçeneğini transaction baslatip yapmanız cok daha saglikli
olur. Neticede commit yapmadiginiz surece size kontrol sansi veriyor.

Ben olayin saniyelere inecegini düşünüyorum.

2 Eki 2017 15:23 tarihinde "Fırat Güleç" <firat(dot)gulec(at)hepsiexpress(dot)com>
yazdı:

> Merhaba,
>
> Cevap veremez duruma düşüyor derken o tabloları kullanan sorgular için bunu
> söylemedim. Bütün db gelen sorgularda problem yaşamıştık, loginler vs bile
> gelmez olmuştu. Bu yüzden lock'dan dolayı olduğunu düşünmüyorum.
>
> Test ortamında bu update'i denedim. Yaklaşık 5 dak da 4.5 milyon kaydı
> update ettim, bir problem yaşamadım, fakat cpu tavan yaptı. Canlıda böyle
> bir update yapacak isem gece saatlerinde yapmayı öngörüyorum. Server'ın
> donanımını ve tuning konularını biraz daha inceleyeceğm.
>
> Yardımlarınız için hepinize teşekkür ederim.
>
>
>
> -----Original Message-----
> From: Devrim Gündüz [mailto:devrim(at)gunduz(dot)org]
> Sent: Sunday, October 1, 2017 10:38 PM
> To: N. Can KIRIK <can(at)epati(dot)com(dot)tr>
> Cc: Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>; Erkan Durmuş
> <derkan(at)gmail(dot)com>; M.Atıf CEYLAN <mehmet(at)atifceylan(dot)com>; pgsql-tr-genel
> <pgsql-tr-genel(at)postgresql(dot)org>
> Subject: Re: [pgsql-tr-genel] Bulk Update
>
>
> Merhabalar,
>
> On Sun, 2017-10-01 at 19:11 +0300, N. Can KIRIK wrote:
> > sanıyorum 5 milyon kaydı etkileyen update sürerken, diğer
> > bağlantılardan da gelen update işlemleri nedeniyle exclusive lock söz
> > konusu oluyor ve bu yüzden cevap veremez duruma düşüyor.
>
> Öyleyse de yazılım sorunu, aynı anda 5 milyon kayıdı birden fazla neden
> update etsinler ki? Fırat Bey açıklar herhalde.
>
> Zaten ya dediğin gibi hocam, ya da donanım/tuning sorunu var.
>
> Saygılar,
> --
> Devrim Gündüz
> EnterpriseDB: https://www.enterprisedb.com PostgreSQL Consultant, Red Hat
> Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>

Merhaba Atif Bey,

Çalışan function aşağıdaki(ilk mailde göndermiştim) “select
receiver_address_fill(316876);” şekilde çağrılıyor.100 100 bu işlem
yapılmıyor. Tekrar ölçüm yaptım 4.02 dak sürdü. Birden fazla update var ve
select çalışıyor, bundan dolayı bu kadar sürdüğünü düşünüyorum. Donanım ile
ilgili bir sıkıntının olduğunu düşünmüyorum.

create or replace function receiver_address_fill(p_record_cnt integer)
returns void

LANGUAGE plpgsql

AS $$

DECLARE

c_delivery RECORD;

cur_rad CURSOR (x_address_id BIGINT, x_receiver_id BIGINT) FOR SELECT *

FROM
receiver_address

WHERE
receiver_id = x_receiver_id AND

address_id = x_address_id;

c_rad RECORD;

BEGIN

FOR c_delivery IN SELECT * FROM delivery WHERE recipient_address_id is
NULL LIMIT p_record_cnt LOOP

OPEN cur_rad(c_delivery.receiver_address_id,c_delivery.receiver_id);

FETCH cur_rad INTO c_rad;

IF c_rad.id IS NOT NULL

THEN

UPDATE delivery SET recipient_address_id = c_rad.id WHERE id =
c_delivery.id;

UPDATE delivery_transaction SET recipient_address_id = c_rad.id WHERE
delivery_id = c_delivery.id;

END IF;

CLOSE cur_rad;

END LOOP;

END;

$$;

*From:* M.Atıf CEYLAN [mailto:mehmet(at)atifceylan(dot)com]
*Sent:* Monday, October 2, 2017 3:44 PM
*To:* Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>
*Cc:* pgsql-tr-genel <pgsql-tr-genel(at)postgresql(dot)org>; Devrim Gündüz <
devrim(at)gunduz(dot)org>; Erkan Durmuş <derkan(at)gmail(dot)com>; N. Can KIRIK <
can(at)epati(dot)com(dot)tr>
*Subject:* RE: [pgsql-tr-genel] Bulk Update

4.5 milyon update icin 5dk çok uzun süre. Muhtemelen bunun nedeni loop ile
ve 100 satir 100 satir bu islemi yamaniz.

Update from seçeneğini transaction baslatip yapmanız cok daha saglikli
olur. Neticede commit yapmadiginiz surece size kontrol sansi veriyor.

Ben olayin saniyelere inecegini düşünüyorum.

2 Eki 2017 15:23 tarihinde "Fırat Güleç" <firat(dot)gulec(at)hepsiexpress(dot)com>
yazdı:

Merhaba,

Cevap veremez duruma düşüyor derken o tabloları kullanan sorgular için bunu
söylemedim. Bütün db gelen sorgularda problem yaşamıştık, loginler vs bile
gelmez olmuştu. Bu yüzden lock'dan dolayı olduğunu düşünmüyorum.

Test ortamında bu update'i denedim. Yaklaşık 5 dak da 4.5 milyon kaydı
update ettim, bir problem yaşamadım, fakat cpu tavan yaptı. Canlıda böyle
bir update yapacak isem gece saatlerinde yapmayı öngörüyorum. Server'ın
donanımını ve tuning konularını biraz daha inceleyeceğm.

Yardımlarınız için hepinize teşekkür ederim.

-----Original Message-----
From: Devrim Gündüz [mailto:devrim(at)gunduz(dot)org]
Sent: Sunday, October 1, 2017 10:38 PM
To: N. Can KIRIK <can(at)epati(dot)com(dot)tr>
Cc: Fırat Güleç <firat(dot)gulec(at)hepsiexpress(dot)com>; Erkan Durmuş
<derkan(at)gmail(dot)com>; M.Atıf CEYLAN <mehmet(at)atifceylan(dot)com>; pgsql-tr-genel
<pgsql-tr-genel(at)postgresql(dot)org>
Subject: Re: [pgsql-tr-genel] Bulk Update

Merhabalar,

On Sun, 2017-10-01 at 19:11 +0300, N. Can KIRIK wrote:
> sanıyorum 5 milyon kaydı etkileyen update sürerken, diğer
> bağlantılardan da gelen update işlemleri nedeniyle exclusive lock söz
> konusu oluyor ve bu yüzden cevap veremez duruma düşüyor.

Öyleyse de yazılım sorunu, aynı anda 5 milyon kayıdı birden fazla neden
update etsinler ki? Fırat Bey açıklar herhalde.

Zaten ya dediğin gibi hocam, ya da donanım/tuning sorunu var.

Saygılar,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com PostgreSQL Consultant, Red Hat
Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR