pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedupdate == delete + insert?
7+ messages / 6 participants
[nested] [flat]
* update == delete + insert?
@ 2006-03-20 22:49 Craig A. James <cjames@modgraph-usa.com>
2006-03-20 22:56 ` Re: update == delete + insert? Jim Buttafuoco <jim@contactbda.com>
2006-03-20 23:22 ` Re: update == delete + insert? Tom Lane <tgl@sss.pgh.pa.us>
2006-03-21 01:38 ` Re: update == delete + insert? Jaime Casanova <systemguards@gmail.com>
0 siblings, 3 replies; 7+ messages in thread
From: Craig A. James @ 2006-03-20 22:49 UTC (permalink / raw)
To: pgsql-performance
I've seen it said here several times that "update == delete + insert". On the other hand, I've noticed that "alter table [add|drop] column ..." is remarkably fast, even for very large tables, which leads me to wonder whether each column's contents are in a file specifically for that column.
My question: Suppose I have a very "wide" set of data, say 100 columns, and one of those columns will be updated often, but the others are fairly static. I have two choices:
Design 1:
create table a (
id integer,
frequently_updated integer);
create table b(
id integer,
infrequently_updated_1 integer,
infrequently_updated_2 integer,
infrequently_updated_3 integer,
... etc.
infrequently_updated_99 integer);
Design 2:
create table c(
id integer,
frequently_updated integer,
infrequently_updated_1 integer,
infrequently_updated_2 integer,
infrequently_updated_3 integer,
... etc.
infrequently_updated_99 integer);
If "update == delete + insert" is strictly true, then "Design 2" would be poor since 99 columns would be moved around with each update. But if columns are actually stored in separate files, the Designs 1 and 2 would be essentially equivalent when it comes to vacuuming.
Thanks,
Craig
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
@ 2006-03-20 22:56 ` Jim Buttafuoco <jim@contactbda.com>
2 siblings, 0 replies; 7+ messages in thread
From: Jim Buttafuoco @ 2006-03-20 22:56 UTC (permalink / raw)
To: Craig A. James <cjames@modgraph-usa.com>; pgsql-performance
go with design 1, update does = delete + insert.
---------- Original Message -----------
From: "Craig A. James" <cjames@modgraph-usa.com>
To: pgsql-performance@postgresql.org
Sent: Mon, 20 Mar 2006 14:49:43 -0800
Subject: [PERFORM] update == delete + insert?
> I've seen it said here several times that "update == delete + insert". On the other hand, I've noticed that
> "alter table [add|drop] column ..." is remarkably fast, even for very large tables, which leads me to wonder
> whether each column's contents are in a file specifically for that column.
>
> My question: Suppose I have a very "wide" set of data, say 100 columns, and one of those columns will be
> updated often, but the others are fairly static. I have two choices:
>
> Design 1:
> create table a (
> id integer,
> frequently_updated integer);
>
> create table b(
> id integer,
> infrequently_updated_1 integer,
> infrequently_updated_2 integer,
> infrequently_updated_3 integer,
> ... etc.
> infrequently_updated_99 integer);
>
> Design 2:
> create table c(
> id integer,
> frequently_updated integer,
> infrequently_updated_1 integer,
> infrequently_updated_2 integer,
> infrequently_updated_3 integer,
> ... etc.
> infrequently_updated_99 integer);
>
> If "update == delete + insert" is strictly true, then "Design 2" would be poor since 99 columns would be moved
> around with each update. But if columns are actually stored in separate files, the Designs 1 and 2 would be
> essentially equivalent when it comes to vacuuming.
>
> Thanks,
> Craig
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
------- End of Original Message -------
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
@ 2006-03-20 23:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2006-03-20 23:22 UTC (permalink / raw)
To: Craig A. James <cjames@modgraph-usa.com>; +Cc: pgsql-performance
"Craig A. James" <cjames@modgraph-usa.com> writes:
> I've seen it said here several times that "update == delete + insert". On the other hand, I've noticed that "alter table [add|drop] column ..." is remarkably fast, even for very large tables, which leads me to wonder whether each column's contents are in a file specifically for that column.
No. The reason "drop column" is fast is that we make no attempt to
remove the data from existing rows; we only mark the column's entry in
the system catalogs as deleted. "add column" is only fast if you are
adding a column with no default (a/k/a default NULL). In that case
likewise we don't have to modify existing rows; the desired behavior
falls out from the fact that the tuple access routines return NULL if
asked to fetch a column beyond those existing in a particular tuple.
You can read about the storage layout in
http://developer.postgresql.org/docs/postgres/storage.html
regards, tom lane
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
@ 2006-03-21 01:38 ` Jaime Casanova <systemguards@gmail.com>
2006-03-21 11:23 ` Re: update == delete + insert? Jim C. Nasby <jnasby@pervasive.com>
2 siblings, 1 reply; 7+ messages in thread
From: Jaime Casanova @ 2006-03-21 01:38 UTC (permalink / raw)
To: Craig A. James <cjames@modgraph-usa.com>; +Cc: pgsql-performance
On 3/20/06, Craig A. James <cjames@modgraph-usa.com> wrote:
> I've seen it said here several times that "update == delete + insert". On the other hand, I've noticed that "alter table [add|drop] column ..." is remarkably fast, even for very large tables, which leads me to wonder whether each column's contents are in a file specifically for that column.
>
> My question: Suppose I have a very "wide" set of data, say 100 columns, and one of those columns will be updated often, but the others are fairly static. I have two choices:
>
> Design 1:
> create table a (
> id integer,
> frequently_updated integer);
>
> create table b(
> id integer,
> infrequently_updated_1 integer,
> infrequently_updated_2 integer,
> infrequently_updated_3 integer,
> ... etc.
> infrequently_updated_99 integer);
>
> Design 2:
> create table c(
> id integer,
> frequently_updated integer,
> infrequently_updated_1 integer,
> infrequently_updated_2 integer,
> infrequently_updated_3 integer,
> ... etc.
> infrequently_updated_99 integer);
>
> If "update == delete + insert" is strictly true, then "Design 2" would be poor since 99 columns would be moved around with each update. But if columns are actually stored in separate files, the Designs 1 and 2 would be essentially equivalent when it comes to vacuuming.
>
> Thanks,
> Craig
>
design 1 is normalized and better
design 2 is denormalized and a bad approach no matter the RDBMS
update does delete + insert, and vacuum is the way to recover the space
--
Atentamente,
Jaime Casanova
"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
2006-03-21 01:38 ` Re: update == delete + insert? Jaime Casanova <systemguards@gmail.com>
@ 2006-03-21 11:23 ` Jim C. Nasby <jnasby@pervasive.com>
2006-03-21 14:12 ` Re: update == delete + insert? Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Jim C. Nasby @ 2006-03-21 11:23 UTC (permalink / raw)
To: Jaime Casanova <systemguards@gmail.com>; +Cc: Craig A. James <cjames@modgraph-usa.com>; pgsql-performance
On Mon, Mar 20, 2006 at 08:38:15PM -0500, Jaime Casanova wrote:
> On 3/20/06, Craig A. James <cjames@modgraph-usa.com> wrote:
> > Design 1:
> > create table a (
> > id integer,
> > frequently_updated integer);
> >
> > create table b(
> > id integer,
> > infrequently_updated_1 integer,
> > infrequently_updated_2 integer,
> > infrequently_updated_3 integer,
> > ... etc.
> > infrequently_updated_99 integer);
> >
> > Design 2:
> > create table c(
> > id integer,
> > frequently_updated integer,
> > infrequently_updated_1 integer,
> > infrequently_updated_2 integer,
> > infrequently_updated_3 integer,
> > ... etc.
> > infrequently_updated_99 integer);
> design 1 is normalized and better
> design 2 is denormalized and a bad approach no matter the RDBMS
How is design 1 denormalized?
> "What they (MySQL) lose in usability, they gain back in benchmarks, and that's
> all that matters: getting the wrong answer really fast."
> Randal L. Schwartz
Where's that quote from?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
2006-03-21 01:38 ` Re: update == delete + insert? Jaime Casanova <systemguards@gmail.com>
2006-03-21 11:23 ` Re: update == delete + insert? Jim C. Nasby <jnasby@pervasive.com>
@ 2006-03-21 14:12 ` Merlin Moncure <mmoncure@gmail.com>
2006-03-21 17:38 ` Re: update == delete + insert? Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 7+ messages in thread
From: Merlin Moncure @ 2006-03-21 14:12 UTC (permalink / raw)
To: Jim C. Nasby <jnasby@pervasive.com>; +Cc: Jaime Casanova <systemguards@gmail.com>; Craig A. James <cjames@modgraph-usa.com>; pgsql-performance
> > design 1 is normalized and better
> > design 2 is denormalized and a bad approach no matter the RDBMS
>
> How is design 1 denormalized?
It isn't :)...he said it is normalized. Design 2 may or may not be
de-normalized (IMO there is not enough information to make that
determination) but as stated it's a good idea to split the table on
practical grounds.
merlin
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: update == delete + insert?
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
2006-03-21 01:38 ` Re: update == delete + insert? Jaime Casanova <systemguards@gmail.com>
2006-03-21 11:23 ` Re: update == delete + insert? Jim C. Nasby <jnasby@pervasive.com>
2006-03-21 14:12 ` Re: update == delete + insert? Merlin Moncure <mmoncure@gmail.com>
@ 2006-03-21 17:38 ` Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 0 replies; 7+ messages in thread
From: Jim C. Nasby @ 2006-03-21 17:38 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Jaime Casanova <systemguards@gmail.com>; Craig A. James <cjames@modgraph-usa.com>; pgsql-performance
On Tue, Mar 21, 2006 at 09:12:08AM -0500, Merlin Moncure wrote:
> > > design 1 is normalized and better
> > > design 2 is denormalized and a bad approach no matter the RDBMS
> >
> > How is design 1 denormalized?
>
> It isn't :)...he said it is normalized. Design 2 may or may not be
> de-normalized (IMO there is not enough information to make that
> determination) but as stated it's a good idea to split the table on
> practical grounds.
Err, sorry, got the number backwards. My point is that 2 isn't
denormalized afaik, at least not based just on the example. But yes, in
a case like this, vertical partitioning can make a lot of sense.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2006-03-21 17:38 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-20 22:49 update == delete + insert? Craig A. James <cjames@modgraph-usa.com>
2006-03-20 22:56 ` Jim Buttafuoco <jim@contactbda.com>
2006-03-20 23:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-03-21 01:38 ` Jaime Casanova <systemguards@gmail.com>
2006-03-21 11:23 ` Jim C. Nasby <jnasby@pervasive.com>
2006-03-21 14:12 ` Merlin Moncure <mmoncure@gmail.com>
2006-03-21 17:38 ` Jim C. Nasby <jnasby@pervasive.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox