| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
| Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, 小波 顾 <guxiaobo1982(at)hotmail(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, chris(dot)ellis(at)shropshire(dot)gov(dot)uk, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Are there plans to add data compression feature to postgresql? |
| Date: | 2008-10-30 22:41:51 |
| Message-ID: | 28357.1225406511@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Thu, Oct 30, 2008 at 4:01 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>> I can't really see trusting Postgres on a filesystem that felt free to
>> compress portions of it. Would the filesystem still be able to guarantee that
>> torn pages won't "tear" across adjacent blocks? What about torn pages that
>> included hint bits being set?
> I can't see PostgreSQL noticing it. PostgreSQL hands the OS a 512byte
> block, the OS compresses it and it's brethren as the go to disk,
> uncompresses as they come out, and as long as what you put in is what
> you get back it shouldn't really matter.
I think Greg's issue is exactly about what guarantees you'll have left
after the data that comes back fails to be the data that went in.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas | 2008-10-30 22:46:02 | Re: a LEFT JOIN problem |
| Previous Message | Tom Lane | 2008-10-30 22:40:10 | Re: Decreasing WAL size effects |