Mike Christensen <mike@kitchenpc.com> writes:
>> On Sat, Sep 17, 2011 at 6:46 PM, Mike Christensen <mike@kitchenpc.com> wrote:
>>
>> What would be really cool is if postgresql took values for body that
>> were over a few k and compressed them and stored them out of line in
>> another table. Luckily for you, that's EXACTLY what it already does.
>> http://www.postgresql.org/docs/9.1/static/storage-toast.html Cool eh?
>>
>
> Man I've been reading this list for years now, and I kept on seeing
> this "TOAST" thing and just figured you people liked it for sandwiches
> or something.
>
> I feel like the programmer who thinks he's smart using a left bitshift
> operator to double an integer value just to find out the compiler
> already takes that optimization anyway. Are you saying I don't
> actually need to de-frag my hard drive these days either?
>
> Thanks for the quick reply! I will design my table in a way that
Do so at your own risk :-)
Depending on the data model, it could still be good for performance to
store the large payload data in a secondary table linked to the main
table containing other data or metadata.
Especially true if the payload fields are quite often small enough to
*not* cause toasting. In that scenario, you could end up with some
very long physical tuples in the main table that will result in a low
tuple/page ratio and heavy disk reading for any query including those
not caring about the payload data itself.
Yet more true if some of the non payload data is frequently updated.
YMMV
> Mike
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 305.321.1144