From: | inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] compression in LO and other fields |
Date: | 1999-11-16 08:41:22 |
Message-ID: | 383118B2.AAC9E730@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> >> LO is a dead end. What we really want to do is eliminate tuple-size
> >> restrictions and then have large ordinary fields (probably of type
> >> bytea) in regular tuples. I'd suggest working on compression in that
> >> context, say as a new data type called "bytez" or something like that.
>
> > It sounds ideal but I remember that Vadim said inserting a 2GB record
> > is not good idea since it will be written into the log too. If it's a
> > necessary limitation from the point of view of WAL, we have to accept
> > it, I think.
>
> LO won't make that any better: the data still goes into a table.
> You'd have 2GB worth of WAL entries either way.
>
> The only thing LO would do for you is divide the data into block-sized
> tuples, so there would be a bunch of little WAL entries instead of one
> big one. But that'd probably be easy to duplicate too. If we implement
> big tuples by chaining together disk-block-sized segments, which seems
> like the most likely approach, couldn't WAL log each segment as a
> separate log entry? If so, there's almost no difference between LO and
> inline field for logging purposes.
>
I don't know LO well.
But seems LO allows partial update.
Big tuples
If so,isn't it a significant difference ?
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | inoue | 1999-11-16 08:45:43 | Re: [HACKERS] compression in LO and other fields |
Previous Message | Hiroshi Inoue | 1999-11-16 05:25:37 | RE: Unique indexes on system tables |