Re: Create TOAST table only if AM needs

On Fri, May 17, 2019 at 3:28 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > - If your AM uses some system other than TOAST to store large values,
> > you are out of luck. You will get TOAST tables whether you want them
> > or not.
>
> Which is aesthetically and indode usage wise annoying, but not
> *terrible*. You get a a bunch of useless pg_class/pg_index entries and a
> few close-to-empty relfilenodes.

OK, that's fair.

> Well, I don't *quite* buy the suboptimal. As far as I can tell, the
> current chunking size doesn't have much going for it for heap either -
> and while a few people (me including) have complained about it, it's not
> that many people either. My impression is that the current chunking is
> essentially a randomly chosen choice without much to go for it, and so
> it's not going to be much different for other AMs.

I don't think that's really quite fair. The size is carefully chosen
so that you can fit 4 rows on a page with no free space left over.
The wisdom of that particular choice is debatable, but think how sad
you'd be if your AM had 4 bytes less free space available on every
page (because, idk, you stored the epoch in the special space, or
whatever). If you could somehow get the system to store your TOAST
chunks in your side table, you'd end up only being able to fit 3 toast
chunks per page, because the remaining space after you put in 3 chunks
would be 4 bytes too small for another chunk. That is really the
pits, because now your toast table is going to be 33% larger than it
would have been otherwise.

> > So I think this basically just doesn't work right now.
>
> I mean, the zheap on tableam code copies more toast code than I'm happy
> about, and it's chunking is somewhat suboptimal, but that's not
> *terrible*. There's no if(zheap) branches outside of zheap related to
> toasting.

I admit to not having studied that terribly closely, so maybe the
situation is not as bad as I think. In any case, it bears saying that
tableam is a remarkable accomplishment regardless of whatever
shortcomings it has in this area or elsewhere. And it's not really
any skin off my neck whether we do anything to improve this for v12 or
not, because no table AM written by me is likely to get deployed
against PostgreSQL 12, so why am I even arguing about this? Am I just
a naturally argumentative person?

Don't answer that...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company