| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Reducing overhead for repeat de-TOASTing |
| Date: | 2008-06-17 02:34:06 |
| Message-ID: | 12180.1213670046@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Comments, better ideas? Anyone think this is too much trouble to take
>> for the problem?
> I definitely think it's worth it, even if it doesn't handle an
> inline-compressed datum.
Yeah. I'm not certain how much benefit we could get there anyway.
If the datum isn't out-of-line then there's a small upper limit on how
big it can be and hence a small upper limit on how long it takes to
decompress. It's not clear that a complicated caching scheme would
pay for itself.
The profile shown here:
http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003081.html
shows that the problem the PostGIS guys are looking at is definitely an
out-of-line case (in fact, it looks like the datum wasn't even compressed).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2008-06-17 03:04:59 | Re: Question about Encoding a Custom Type |
| Previous Message | Tom Lane | 2008-06-17 01:43:37 | Re: Crash in pgCrypto? |