Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Amit Kapila
On Mon, Oct 26, 2015 at 12:07 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > On Mon, Oct 26, 2015 at 10:19 AM, Amit Kapila > wrote: >> >> >> I think Oracle just copies the changed part of old row to rollback >> segment. >> Also in Redo logs, it just

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Ashutosh Bapat
On Mon, Oct 26, 2015 at 4:09 PM, Amit Kapila wrote: > On Mon, Oct 26, 2015 at 12:07 PM, Ashutosh Bapat < > ashutosh.ba...@enterprisedb.com> wrote: > >> >> >> On Mon, Oct 26, 2015 at 10:19 AM, Amit Kapila >> wrote: >>> >>> >>> I think Oracle just

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Ashutosh Bapat
On Mon, Oct 26, 2015 at 10:19 AM, Amit Kapila wrote: > On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов > wrote: > > > > > > - Цитат от Kisung Kim (ks...@bitnine.co.kr), на 26.10.2015 в 04:36 > - > > > > > However, what I want to know is about

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Jim Nasby
On 10/25/15 9:36 PM, Kisung Kim wrote: I want to explain for our clients that PG's update performance is comparable to Oracle's. There's really only 2 ways you can answer that. You can either handwave the question away ("Yes, update performance is comparable."), or you have to do actual

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Gavin Flower
On 27/10/15 11:37, Jim Nasby wrote: On 10/25/15 9:36 PM, Kisung Kim wrote: I want to explain for our clients that PG's update performance is comparable to Oracle's. There's really only 2 ways you can answer that. You can either handwave the question away ("Yes, update performance is

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread Amit Kapila
On Mon, Oct 26, 2015 at 4:31 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > On Mon, Oct 26, 2015 at 4:09 PM, Amit Kapila > wrote: > >> On Mon, Oct 26, 2015 at 12:07 PM, Ashutosh Bapat < >> ashutosh.ba...@enterprisedb.com> wrote: >> >>> >>> >>> On Mon,

Re: [HACKERS] questions about PG update performance

2015-10-26 Thread José Luis Tallón
On 10/26/2015 05:49 AM, Amit Kapila wrote: On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов > wrote: > > > - Цитат от Kisung Kim (ks...@bitnine.co.kr ), на 26.10.2015 в 04:36 - > > > However, what I want to know

Re: [HACKERS] questions about PG update performance

2015-10-25 Thread Kisung Kim
2015-10-26 11:12 GMT+09:00 Michael Paquier : > > > On Mon, Oct 26, 2015 at 10:52 AM, Kisung Kim wrote: > >> Because of the internal implementation of MVCC in PG >> the update of a row is actually a insertion of a new version row. >> So if the size

Re: [HACKERS] questions about PG update performance

2015-10-25 Thread Любен Каравелов
- Цитат от Kisung Kim (ks...@bitnine.co.kr), на 26.10.2015 в 04:36 - > However, what I want to know is about the update performance difference > between PG and Oracle if there any. > The case I described is for exaggerating the difference between PG and > Oracle. > > I want to explain

Re: [HACKERS] questions about PG update performance

2015-10-25 Thread Amit Kapila
On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов wrote: > > > - Цитат от Kisung Kim (ks...@bitnine.co.kr), на 26.10.2015 в 04:36 - > > > However, what I want to know is about the update performance difference > > between PG and Oracle if there any. > > The case I

[HACKERS] questions about PG update performance

2015-10-25 Thread Kisung Kim
Dear, I have a question about update performance of PG. Because of the internal implementation of MVCC in PG the update of a row is actually a insertion of a new version row. So if the size of a row is huge, then it incurs some overhead compare to in-place update strategy. Let's assume that a

Re: [HACKERS] questions about PG update performance

2015-10-25 Thread Michael Paquier
On Mon, Oct 26, 2015 at 10:52 AM, Kisung Kim wrote: > Because of the internal implementation of MVCC in PG > the update of a row is actually a insertion of a new version row. > So if the size of a row is huge, then it incurs some overhead compare to > in-place update