Added to TODO: * Research storing disk pages with no alignment/padding --------------------------------------------------------------------------- Lincoln Yeoh wrote: > I believe that one should leave such on-the-fly disk compression to the > O/S. Postgresql already does compression for TOAST. > > However, maybe padding for alignment is a waste on the disk - disks being > so much slower than CPUs (not sure about that once the data is in memory ). > Maybe there should be an option to reorder columns so that less space is > wasted. > > At 05:47 PM 7/17/2005 -0500, Jim C. Nasby wrote: > > >On Sat, Jul 16, 2005 at 03:18:24PM -0700, Ron Mayer wrote: > > > > > If that were practical, even more radical I/O saving tricks might be > > > possible beyond removing alignment bytes - like some compression algorithm. > > > >True, though there's a few issues with zlib compression. First, you have > >to be able to pull specific pages out of the files on disk. Right now > >that's trivial; you just read bytes xxx - yyy. With compression things > >are more difficult, because you no longer have a fixed page size. > > > >methods. Another factor is that more complex compression methods will be > >much more CPU intensive. > > > >FWIW, the way oracle handles compression is as a one-time operation. > >When you tell it to compress a table it will re-write the entire table, > >compressing it as it goes. But any pages that get changed after that > >will end up uncompressed. Of course in a data warehouse environment > >that's perfectly acceptable. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@xxxxxxxxxxxxxxxx | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
