Re: TOAST versus toast

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: TOAST versus toast
Date: 2025-03-17 04:24:49
Message-ID: 3915173.1742185489@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <jan(at)wi3ck(dot)info> writes:
> As the original author of the TOAST I vote for TOAST being used as the
> name/acronym of the feature, but toast in all other cases like as verb.

Well, if we're appealing to history ... I dug in the archives
and found that you seem to have invented the name here [1]:

Since we decided not to create a separate LONG datatype, and
not doing LONG attributes alone (compression at some point
too), I looked for some unique name for it - and found one.
The characters 'toast' did not show up on a case insensitive
grep over the entire CVS tree. Thus, I'll call it

tuple toaster

subsequently. I think there are enough similarities to a
toaster in this case. If you take a bread (tuple) and toast
some of the slices (attributes), anything can work as you
want and it will smell and taste delicious. In some cases,
slices might get burned (occationally hitting an indexed
value), taste bitter and it will stink.

BTW: The idea itself was stolen from toast/untoast, a GSM
voice data compression/decompression tool.

Note the lack of any upper case. Shortly later we reverse-engineered
an acronym for it [2], with the winner being Tom Lockhart's

The Oversized-Attribute Storage Technique

So I'd say that the basis for upper-casing it at all is mighty
thin; it was not conceived as an acronym to begin with. We should
probably adjust our glossary entry for it to nod in the direction
of that GSM tool, if anyone can find a modern reference for that.

regards, tom lane

[1] https://www.postgresql.org/message-id/m120C3U-0003kHC%40orion.SAPserv.Hamburg.dsh.de
[2] https://www.postgresql.org/message-id/flat/m120DHd-0003kLC%40orion.SAPserv.Hamburg.dsh.de

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniil Davydov 2025-03-17 04:49:45 Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM
Previous Message vignesh C 2025-03-17 03:56:47 Re: Commit fest 2025-03