Mike Christensen writes:

On Sat, Sep 17, 2011 at 6:46 PM, Mike Christensen 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.


Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 305.321.1144

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 5 | next ›
Discussion Overview
grouppgsql-general @
postedSep 18, '11 at 12:46a
activeSep 19, '11 at 10:30p



site design / logo © 2021 Grokbase