| From: | "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl> |
|---|---|
| To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Significantly larger toast tables on 8.4? |
| Date: | 2009-01-02 20:23:13 |
| Message-ID: | 20090102202313.GA18016@cuci.nl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alex Hunsaker wrote:
>I think we could just add another toast storage type: alter table
>alter column set storage compress; ? It seems overkill to expose
>PGLZ_Strategy knobs per column...
Three things:
a. Shouldn't it in theory be possible to have a decompression algorithm
which is IO-bound because it decompresses faster than the disk can
supply the data? (On common current hardware).
b. Has the current algorithm been carefully benchmarked and/or optimised
and/or chosen to fit the IO-bound target as close as possible?
c. Are there any well-known pitfalls/objections which would prevent me from
changing the algorithm to something more efficient (read: IO-bound)?
--
Sincerely,
Stephen R. van den Berg.
"Always remember that you are unique. Just like everyone else."
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-01-02 20:35:18 | Re: Significantly larger toast tables on 8.4? |
| Previous Message | Tom Lane | 2009-01-02 20:01:45 | Re: posix_fadvise v22 |