Re: Are there plans to add data compression feature to postgresql?
От | Gregory Stark |
---|---|
Тема | Re: Are there plans to add data compression feature to postgresql? |
Дата | |
Msg-id | 87k5bpaaw4.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Are there plans to add data compression feature to postgresql? ("Scott Marlowe" <scott.marlowe@gmail.com>) |
Ответы |
Re: Are there plans to add data compression feature to postgresql?
|
Список | pgsql-general |
"Scott Marlowe" <scott.marlowe@gmail.com> writes: > On Thu, Oct 30, 2008 at 4:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Scott Marlowe" <scott.marlowe@gmail.com> writes: >>> On Thu, Oct 30, 2008 at 4:01 PM, Gregory Stark <stark@enterprisedb.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. > > Sounds kinda hand wavy to me. If compressed file systems didn't give > you back what you gave them I couldn't imagine them being around for > very long. I don't know, NFS has lasted quite a while. So you tell me, I write 512 bytes of data to a compressed filesystem, how does it handle the torn page problem? Is it going to have to WAL log all data operations again? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
В списке pgsql-general по дате отправления: