Re: TOAST versus toast - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TOAST versus toast
Date
Msg-id 3915173.1742185489@sss.pgh.pa.us
Whole thread Raw
In response to Re: TOAST versus toast  (Jan Wieck <jan@wi3ck.info>)
Responses Re: TOAST versus toast
List pgsql-hackers
Jan Wieck <jan@wi3ck.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



pgsql-hackers by date:

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