Mike Christensen <mike@xxxxxxxxxxxxx> writes: >> On Sat, Sep 17, 2011 at 6:46 PM, Mike Christensen <mike@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@xxxxxxxxxxx p: 305.321.1144 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
