Varchar columns

Sibimon Philip

Varchar columns
> We use hardware compression in our environment. So do we need to use
> VARCHAR column to save storage? VARCHAR take more CPU processing and more
> programming, so I would like to avoid using VARCHAR if we do not gain any
> storage Or any other benefits.
>
> Please let me know if anybody has any opinion on this.
>
>
> Thanks
> Sibimon Philip
> 972-702-2515 - Office
> 972-417-3597 - Residence
> E-mail - [login to unmask email]
>

Venkat (PCA) Pillay

Re: Varchar columns
(in response to Sibimon Philip)
Sibimon

This is more design issue. In future if you have a possibility to
increase the column length then VARCHAR is ideal because V6 or V5 with APAR,
lets you increase the VARCHAR length thru ALTER statement but if you stick
with CHAR then you don't have that option left.

Regards
Pillay
> -----Original Message-----
> From: Philip, Sibimon [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 1:05 PM
> To: [login to unmask email]
> Subject: Varchar columns
>
> > We use hardware compression in our environment. So do we need to use
> > VARCHAR column to save storage? VARCHAR take more CPU processing and
> more
> > programming, so I would like to avoid using VARCHAR if we do not gain
> any
> > storage Or any other benefits.
> >
> > Please let me know if anybody has any opinion on this.
> >
> >
> > Thanks
> > Sibimon Philip
> > 972-702-2515 - Office
> > 972-417-3597 - Residence
> > E-mail - [login to unmask email]
> >

Jim Drewe

Re: Varchar columns
(in response to Venkat (PCA) Pillay)
If you find hardware compression acceptable, then you shouldn't need
VARCHARs. Essentially you make the table a varying length table anyway with
compression so the VARCHAR is extraneous work on the central processor. You
will have to watch your NEARINDREF and FARINDREF statistics with compression
to let you know when to reorganize.

Jim



From: [login to unmask email] on 10/06/99 10:10 AM
To: [login to unmask email]
cc: (bcc: James Drewe)
Subject: Varchar columns

> We use hardware compression in our environment. So do we need to use
> VARCHAR column to save storage? VARCHAR take more CPU processing and more
> programming, so I would like to avoid using VARCHAR if we do not gain any
> storage Or any other benefits.
>
> Please let me know if anybody has any opinion on this.
>
>
> Thanks
> Sibimon Philip
> 972-702-2515 - Office
> 972-417-3597 - Residence
> E-mail - [login to unmask email]
>

sanjay jain

Re: Varchar columns
(in response to Jim Drewe)
Jim,

Can you elaborate how compression might affect NEARINDREF and FARINDREF
stats ?

Sanjay

-----Original Message-----
From: James Drewe <[login to unmask email]>
Newsgroups: bit.listserv.db2-l
To: [login to unmask email] <[login to unmask email]>
Date: Wednesday, October 06, 1999 1:44 PM
Subject: Re: Varchar columns


>If you find hardware compression acceptable, then you shouldn't need
>VARCHARs. Essentially you make the table a varying length table anyway
with
>compression so the VARCHAR is extraneous work on the central processor.
You
>will have to watch your NEARINDREF and FARINDREF statistics with
compression
>to let you know when to reorganize.
>
>Jim
>
>
>
>From: [login to unmask email] on 10/06/99 10:10 AM
>To: [login to unmask email]
>cc: (bcc: James Drewe)
>Subject: Varchar columns
>
>> We use hardware compression in our environment. So do we need to use
>> VARCHAR column to save storage? VARCHAR take more CPU processing and more
>> programming, so I would like to avoid using VARCHAR if we do not gain any
>> storage Or any other benefits.
>>
>> Please let me know if anybody has any opinion on this.
>>
>>
>> Thanks
>> Sibimon Philip
>> 972-702-2515 - Office
>> 972-417-3597 - Residence
>> E-mail - [login to unmask email]
>>

Richard A Yevich

Re: Varchar columns
(in response to sanjay jain)
DB2 Compression is row level compression, and results in varying length
rows, with all the same implications as having a VARCHAR in a non-compressed
row. Therefore, NEARINDREF and FARINDREF are always possible since any row
updated will probably never be the same length. After the update, and due
to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or PKZIP
style), changes generally do not compress or do not compress to the same
length -- row length quite often increases. If there is no available space
on the page, then you get the INDEFS as the row must be moved to another
page.

Richard Yevich
+=====+======+
Information Technology Consulting, Data Modeling, Advanced Education
RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
DB2® Family and Oracle® Specialists - Parallel Technologies
VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999

> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
> sanjay jain
> Sent: Wednesday, October 06, 1999 5:34 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
>
> Jim,
>
> Can you elaborate how compression might affect NEARINDREF and FARINDREF
> stats ?
>
> Sanjay
>
> -----Original Message-----
> From: James Drewe <[login to unmask email]>
> Newsgroups: bit.listserv.db2-l
> To: [login to unmask email] <[login to unmask email]>
> Date: Wednesday, October 06, 1999 1:44 PM
> Subject: Re: Varchar columns
>
>
> >If you find hardware compression acceptable, then you shouldn't need
> >VARCHARs. Essentially you make the table a varying length table anyway
> with
> >compression so the VARCHAR is extraneous work on the central processor.
> You
> >will have to watch your NEARINDREF and FARINDREF statistics with
> compression
> >to let you know when to reorganize.
> >
> >Jim
> >
> >
> >
> >From: [login to unmask email] on 10/06/99 10:10 AM
> >To: [login to unmask email]
> >cc: (bcc: James Drewe)
> >Subject: Varchar columns
> >
> >> We use hardware compression in our environment. So do we need to use
> >> VARCHAR column to save storage? VARCHAR take more CPU
> processing and more
> >> programming, so I would like to avoid using VARCHAR if we do
> not gain any
> >> storage Or any other benefits.
> >>
> >> Please let me know if anybody has any opinion on this.
> >>
> >>
> >> Thanks
> >> Sibimon Philip
> >> 972-702-2515 - Office
> >> 972-417-3597 - Residence
> >> E-mail - [login to unmask email]
> >>
>

Sibimon Philip

Re: Varchar columns
(in response to Richard A Yevich)
Thanks to everyone for answering the question. But I got few more, if the
compression is made by hardware

1. When is the compression happening? Is it at the time of writing into DASD
from write buffer?.
2. When does de-compression happens? Is it while reading to buffer pool?
3. If the decompression is happening while reading from DASD, does it means
one page need more than one buffer pool to hold the data.

Thanks
Sibimon Philip

-----Original Message-----
From: Richard A Yevich [mailto:[login to unmask email]
Sent: Thursday, October 07, 1999 4:07 PM
To: [login to unmask email]
Subject: Re: Varchar columns


DB2 Compression is row level compression, and results in varying length
rows, with all the same implications as having a VARCHAR in a non-compressed
row. Therefore, NEARINDREF and FARINDREF are always possible since any row
updated will probably never be the same length. After the update, and due
to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or PKZIP
style), changes generally do not compress or do not compress to the same
length -- row length quite often increases. If there is no available space
on the page, then you get the INDEFS as the row must be moved to another
page.

Richard Yevich
+=====+======+
Information Technology Consulting, Data Modeling, Advanced Education
RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
DB2® Family and Oracle® Specialists - Parallel Technologies
VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999

> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
> sanjay jain
> Sent: Wednesday, October 06, 1999 5:34 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
>
> Jim,
>
> Can you elaborate how compression might affect NEARINDREF and FARINDREF
> stats ?
>
> Sanjay
>
> -----Original Message-----
> From: James Drewe <[login to unmask email]>
> Newsgroups: bit.listserv.db2-l
> To: [login to unmask email] <[login to unmask email]>
> Date: Wednesday, October 06, 1999 1:44 PM
> Subject: Re: Varchar columns
>
>
> >If you find hardware compression acceptable, then you shouldn't need
> >VARCHARs. Essentially you make the table a varying length table anyway
> with
> >compression so the VARCHAR is extraneous work on the central processor.
> You
> >will have to watch your NEARINDREF and FARINDREF statistics with
> compression
> >to let you know when to reorganize.
> >
> >Jim
> >
> >
> >
> >From: [login to unmask email] on 10/06/99 10:10 AM
> >To: [login to unmask email]
> >cc: (bcc: James Drewe)
> >Subject: Varchar columns
> >
> >> We use hardware compression in our environment. So do we need to use
> >> VARCHAR column to save storage? VARCHAR take more CPU
> processing and more
> >> programming, so I would like to avoid using VARCHAR if we do
> not gain any
> >> storage Or any other benefits.
> >>
> >> Please let me know if anybody has any opinion on this.
> >>
> >>
> >> Thanks
> >> Sibimon Philip
> >> 972-702-2515 - Office
> >> 972-417-3597 - Residence
> >> E-mail - [login to unmask email]
> >>
>

Francis C - CNF Leblanc

Re: Varchar columns
(in response to Sibimon Philip)
Although I didn't post the initial question, I've been watching with great
interest. This discussion in my team has posed a few additional questions.


First, we believe that if no length is supplied when inserting a varchar
value, then DB2 determines the length essentially by checking for trailing
nulls. Is there a way for DB2 to set the length by checking for trailing
spaces?

Second, assuming the use of hardware compression, how can we predict the
effect on DB2 logging, and is the effect even big enough to worry about?

Third, also assuming hardware compression, how does this affect the use of
CA-Platinum Log Analyzer, or similar products if the table is reloaded
and/or reorganized? We're assuming that we would need to specify
keepdictionary.

> -----Original Message-----
> From: Richard A Yevich [SMTP:[login to unmask email]
> Sent: Thursday, October 07, 1999 2:07 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
> DB2 Compression is row level compression, and results in varying length
> rows, with all the same implications as having a VARCHAR in a
> non-compressed
> row. Therefore, NEARINDREF and FARINDREF are always possible since any
> row
> updated will probably never be the same length. After the update, and due
> to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or
> PKZIP
> style), changes generally do not compress or do not compress to the same
> length -- row length quite often increases. If there is no available
> space
> on the page, then you get the INDEFS as the row must be moved to another
> page.
>
> Richard Yevich
> +=====+======+
> Information Technology Consulting, Data Modeling, Advanced Education
> RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
> Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
> DB2® Family and Oracle® Specialists - Parallel Technologies
> VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
> Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999
>
> > -----Original Message-----
> > From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
> > sanjay jain
> > Sent: Wednesday, October 06, 1999 5:34 PM
> > To: [login to unmask email]
> > Subject: Re: Varchar columns
> >
> >
> > Jim,
> >
> > Can you elaborate how compression might affect NEARINDREF and FARINDREF
> > stats ?
> >
> > Sanjay
> >
> > -----Original Message-----
> > From: James Drewe <[login to unmask email]>
> > Newsgroups: bit.listserv.db2-l
> > To: [login to unmask email] <[login to unmask email]>
> > Date: Wednesday, October 06, 1999 1:44 PM
> > Subject: Re: Varchar columns
> >
> >
> > >If you find hardware compression acceptable, then you shouldn't need
> > >VARCHARs. Essentially you make the table a varying length table anyway
> > with
> > >compression so the VARCHAR is extraneous work on the central processor.
> > You
> > >will have to watch your NEARINDREF and FARINDREF statistics with
> > compression
> > >to let you know when to reorganize.
> > >
> > >Jim
> > >
> > >
> > >
> > >From: [login to unmask email] on 10/06/99 10:10 AM
> > >To: [login to unmask email]
> > >cc: (bcc: James Drewe)
> > >Subject: Varchar columns
> > >
> > >> We use hardware compression in our environment. So do we need to use
> > >> VARCHAR column to save storage? VARCHAR take more CPU
> > processing and more
> > >> programming, so I would like to avoid using VARCHAR if we do
> > not gain any
> > >> storage Or any other benefits.
> > >>
> > >> Please let me know if anybody has any opinion on this.
> > >>
> > >>
> > >> Thanks
> > >> Sibimon Philip
> > >> 972-702-2515 - Office
> > >> 972-417-3597 - Residence
> > >> E-mail - [login to unmask email]
> > >>
> >

Chris Blaicher

Re: Varchar columns
(in response to Francis C - CNF Leblanc)
Compression, either hardware or software, is done at the row level before a
row is added to a page. It is de-compressed after a row is selected from a
page. All pages on DASD are the same size based upon the page size
specified at creation of the tablespace. A page on DASD only takes a page
in the bufferpool.

Note: only those rows selected from a page are de-compressed, not all rows
on the page. The row, not the page is compressed. As a matter of fact,
there are times that a 'compressed' row would take more space than a
non-compressed row. In those cases the un-compressed row is written to the
page. A bit in the row header indicates if the row is compressed or not.

I hope this clarifies it a little for you.

Chris Blaicher
BMC Software, Inc.
Austin Research Labs
[login to unmask email]

-----Original Message-----
From: Philip, Sibimon [mailto:[login to unmask email]
Sent: Thursday, October 07, 1999 5:01 PM
To: [login to unmask email]
Subject: Re: Varchar columns


Thanks to everyone for answering the question. But I got few more, if the
compression is made by hardware

1. When is the compression happening? Is it at the time of writing into DASD
from write buffer?.
2. When does de-compression happens? Is it while reading to buffer pool?
3. If the decompression is happening while reading from DASD, does it means
one page need more than one buffer pool to hold the data.

Thanks
Sibimon Philip

-----Original Message-----
From: Richard A Yevich [mailto:[login to unmask email]
Sent: Thursday, October 07, 1999 4:07 PM
To: [login to unmask email]
Subject: Re: Varchar columns


DB2 Compression is row level compression, and results in varying length
rows, with all the same implications as having a VARCHAR in a non-compressed
row. Therefore, NEARINDREF and FARINDREF are always possible since any row
updated will probably never be the same length. After the update, and due
to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or PKZIP
style), changes generally do not compress or do not compress to the same
length -- row length quite often increases. If there is no available space
on the page, then you get the INDEFS as the row must be moved to another
page.

Richard Yevich
+=====+======+
Information Technology Consulting, Data Modeling, Advanced Education
RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
DB2® Family and Oracle® Specialists - Parallel Technologies
VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999

> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
> sanjay jain
> Sent: Wednesday, October 06, 1999 5:34 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
>
> Jim,
>
> Can you elaborate how compression might affect NEARINDREF and FARINDREF
> stats ?
>
> Sanjay
>
> -----Original Message-----
> From: James Drewe <[login to unmask email]>
> Newsgroups: bit.listserv.db2-l
> To: [login to unmask email] <[login to unmask email]>
> Date: Wednesday, October 06, 1999 1:44 PM
> Subject: Re: Varchar columns
>
>
> >If you find hardware compression acceptable, then you shouldn't need
> >VARCHARs. Essentially you make the table a varying length table anyway
> with
> >compression so the VARCHAR is extraneous work on the central processor.
> You
> >will have to watch your NEARINDREF and FARINDREF statistics with
> compression
> >to let you know when to reorganize.
> >
> >Jim
> >
> >
> >
> >From: [login to unmask email] on 10/06/99 10:10 AM
> >To: [login to unmask email]
> >cc: (bcc: James Drewe)
> >Subject: Varchar columns
> >
> >> We use hardware compression in our environment. So do we need to use
> >> VARCHAR column to save storage? VARCHAR take more CPU
> processing and more
> >> programming, so I would like to avoid using VARCHAR if we do
> not gain any
> >> storage Or any other benefits.
> >>
> >> Please let me know if anybody has any opinion on this.
> >>
> >>
> >> Thanks
> >> Sibimon Philip
> >> 972-702-2515 - Office
> >> 972-417-3597 - Residence
> >> E-mail - [login to unmask email]
> >>
>

Richard A Yevich

Re: Varchar columns
(in response to Chris Blaicher)
> 1. When is the compression happening? Is it at the time of
> writing into DASD from write buffer?.

DB2 compression occurs in the DB2 buffer. It has nothing to do with DASD
compression.

DASD compression occurs in the storage device and has nothing to do with DB2
compression.

DB2 compression is row level and not all data and not all rows are
compressed. But when that page gets to DASD, the entire page is DASD level
compressed. This is all goodness.

> 2. When does de-compression happens? Is it while reading to buffer pool?

DB2 compression occurs whenever the data needs to be examined. The data in
the page in the buffer pool is compressed, and decompressed on lifting it
out.

> 3. If the decompression is happening while reading from DASD,
> does it means one page need more than one buffer pool to hold the data.

Not relevant -- as per the other answers.

Richard Yevich
+=====+======+
Information Technology Consulting, Data Modeling, Advanced Education
RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
DB2® Family and Oracle® Specialists - Parallel Technologies
VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999

Richard A Yevich

Re: Varchar columns
(in response to Richard A Yevich)
> Although I didn't post the initial question, I've been watching with great
> interest. This discussion in my team has posed a few additional
> questions.
> First, we believe that if no length is supplied when inserting a varchar
> value, then DB2 determines the length essentially by checking for trailing
> nulls. Is there a way for DB2 to set the length by checking for trailing
> spaces?

DB2 determines the length of the VARCHAR from the length you supply.

> Second, assuming the use of hardware compression, how can we predict the
> effect on DB2 logging, and is the effect even big enough to worry about?

Is you are talking about DB2 compression, nothing to worry about. DASD
level compression and logging have nothing to do with each other. If the
DASD device is doing storage compression, fine. Not your concern (as in the
RVA devices).
>
> Third, also assuming hardware compression, how does this affect the use of
> CA-Platinum Log Analyzer, or similar products if the table is reloaded
> and/or reorganized? We're assuming that we would need to specify
> keepdictionary.

Again, are you talking DB2 compression or DASD device compression? In
either case, it is not a concern to you as the dictionary is stored in the
front of the tablespace and any changes to it or data is kept on the log.
DB2 compression has been around for many years and has no problems when it
comes to logging, etc., and all vendor utilities have no problem with it.

KEEP DICTIONARY means not to rebuild the dictionary when you REORG. You
need to watch the catalog statistics and when the dictionary begins to lose
its effectiveness, you should rebuild it.

Richard Yevich
+=====+======+
Information Technology Consulting, Data Modeling, Advanced Education
RYC® Inc. USA: 1-800-664-2421 Int'l: 1-305-361-8585 Fax: 1-512-476-3930
Web: < http://www.ryci.com > Email: [login to unmask email] Offices: USA and Europe
DB2® Family and Oracle® Specialists - Parallel Technologies
VLDB and Data Sharing Technologies (specialties SAP®, Peoplesoft®)
Authors of "DB2 Answers" by Osborne-McGraw Hill, May, 1999

Kirk Hampton

Re: Varchar columns
(in response to Richard A Yevich)


I have seen other posts here that reference 'hardware compression',
and I have to ask, are we talking about something that happens in a DASD
subsystem and/or cache controller, as opposed to the tablespace attribute
COMPRESS YES, which would be, I suppose, classified as 'software
compression' ? How is hardware compression enabled/disabled ?









"Leblanc, Francis C - CNF" <[login to unmask email]> on 10/07/99 05:27:03 PM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

To: [login to unmask email]
cc: (bcc: Kirk Hampton/Texas Utilities)
Subject: Re: Varchar columns




Although I didn't post the initial question, I've been watching with great
interest. This discussion in my team has posed a few additional questions.


First, we believe that if no length is supplied when inserting a varchar
value, then DB2 determines the length essentially by checking for trailing
nulls. Is there a way for DB2 to set the length by checking for trailing
spaces?

Second, assuming the use of hardware compression, how can we predict the
effect on DB2 logging, and is the effect even big enough to worry about?

Third, also assuming hardware compression, how does this affect the use of
CA-Platinum Log Analyzer, or similar products if the table is reloaded
and/or reorganized? We're assuming that we would need to specify
keepdictionary.

> -----Original Message-----
> From: Richard A Yevich [SMTP:[login to unmask email]
> Sent: Thursday, October 07, 1999 2:07 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
> DB2 Compression is row level compression, and results in varying length
> rows, with all the same implications as having a VARCHAR in a
> non-compressed
> row. Therefore, NEARINDREF and FARINDREF are always possible since any
> row
> updated will probably never be the same length. After the update, and due
> to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or
> PKZIP
> style), changes generally do not compress or do not compress to the same
> length -- row length quite often increases. If there is no available
> space
> on the page, then you get the INDEFS as the row must be moved to another
> page.
>
> Richard Yevich
> +=====+======+
> Information Technology Consulting, Data Modeling, Advanced Education
> RYC

Richard A Yevich

Re: Varchar columns
(in response to Kirk Hampton)
DB2 compression is either hardware or software. Hardware assisted DB2
compression is enabled if the feature is installed. Software is normally
for backup.

There is also hardware compression in the DASD Storage devices and this is a
completely different issue, and should not even be our concern. It is a
native method used by the devices to store data.

> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
> Kirk Hampton
> Sent: Thursday, October 07, 1999 6:50 PM
> To: [login to unmask email]
> Subject: Re: Varchar columns
>
>
>
>
> I have seen other posts here that reference 'hardware compression',
> and I have to ask, are we talking about something that happens in a DASD
> subsystem and/or cache controller, as opposed to the tablespace attribute
> COMPRESS YES, which would be, I suppose, classified as 'software
> compression' ? How is hardware compression enabled/disabled ?
>
>
>
>
>
>
>
>
>
> "Leblanc, Francis C - CNF" <[login to unmask email]> on 10/07/99
> 05:27:03 PM
>
> Please respond to DB2 Data Base Discussion List <[login to unmask email]>
>
> To: [login to unmask email]
> cc: (bcc: Kirk Hampton/Texas Utilities)
> Subject: Re: Varchar columns
>
>
>
>
> Although I didn't post the initial question, I've been watching with great
> interest. This discussion in my team has posed a few additional
> questions.
>
>
> First, we believe that if no length is supplied when inserting a varchar
> value, then DB2 determines the length essentially by checking for trailing
> nulls. Is there a way for DB2 to set the length by checking for trailing
> spaces?
>
> Second, assuming the use of hardware compression, how can we predict the
> effect on DB2 logging, and is the effect even big enough to worry about?
>
> Third, also assuming hardware compression, how does this affect the use of
> CA-Platinum Log Analyzer, or similar products if the table is reloaded
> and/or reorganized? We're assuming that we would need to specify
> keepdictionary.
>
> > -----Original Message-----
> > From: Richard A Yevich [SMTP:[login to unmask email]
> > Sent: Thursday, October 07, 1999 2:07 PM
> > To: [login to unmask email]
> > Subject: Re: Varchar columns
> >
> > DB2 Compression is row level compression, and results in varying length
> > rows, with all the same implications as having a VARCHAR in a
> > non-compressed
> > row. Therefore, NEARINDREF and FARINDREF are always possible since any
> > row
> > updated will probably never be the same length. After the
> update, and due
> > to the dictionary style compression (Lempel-Ziv Welch Algorithm -- or
> > PKZIP
> > style), changes generally do not compress or do not compress to the same
> > length -- row length quite often increases. If there is no available
> > space
> > on the page, then you get the INDEFS as the row must be moved to another
> > page.
> >
> > Richard Yevich
> > +=====+======+
> > Information Technology Consulting, Data Modeling, Advanced Education
> > RYC