| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: ERROR: missing chunk number 0 for toast value |
| Date: | 2014-01-06 18:13:11 |
| Message-ID: | 7300.1389031991@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Is "forcibly detoast everything" a complete no-go? I realize there
> are performance concerns with that approach, but I'm not sure how
> realistic a worry it actually is.
It's certainly possible to think of scenarios under which it'd be painful,
eg, you fetch all columns into a record but you never actually use the
toasted one(s). OTOH, I can think of cases where forced detoasting might
save cycles too, if it prevents multiple detoastings on later accesses.
Probably what we ought to do is put together a trial patch and try to
do some benchmarking. I agree that this is the simplest route to a
fix if we can stand the overhead.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Johnston | 2014-01-06 18:15:59 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier |
| Previous Message | Andres Freund | 2014-01-06 18:05:34 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier |