Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: David Steele <david(at)pgmasters(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist
Date: 2018-04-10 13:11:47
Message-ID: 21764030.lqeCNNN3KP@x200m
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от 10 апреля 2018 08:55:52 пользователь David Steele написал:
> On 1/25/18 12:27 PM, Nikolay Shaplov wrote:
> > В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал:
> >> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> >>> Tom Lane wrote:
> >>>> Well, maybe the right answer is to address that. It's clear to me
> >>>> why that would happen if we store these things as reloptions on the
> >>>> toast table, but can't they be stored on the parent table?
> >>>
> >>> Actually, Nikolay provided a possible solution: if you execute ALTER
> >>> TABLE SET (toast.foobar = xyz), and a toast table doesn't exist, create
> >>> one at that point.
> >>
> >> That adds a lot of overhead if you never actually need the toast table.
> >
> > I think this overhead case is not that terrible if it is properly warned
> > ;-)>
> >> Still, maybe it's an appropriate amount of effort compared to the size
> >> of the use-case for this.
> >
> > If you came to some final conclustion, please close the commiffest item
> > with "Return with feedback" resolution, and I write another patch...
>
> I think this patch should be marked Returned with Feedback since it
> appears there is no consensus on whether it is useful or correct, so I
> have done that.
Exactly!

But I'd like to know what kind of feedback is it :-)
What conclusion have been reached (I did not got it)

Otherwise I would not know how to rewrite this patch.

I would suggest: create a TOAST relation whenever toast.* options is set, but
give a warning it this relation will not be used for data storage (i.e. there
is no toastable columns in the table)

But I need some confirmation, in order not to write patch in vain again :-)

>
> If I got it wrong I'm happy to move it to the next CF in Waiting for
> Author state instead.
>
> Thanks,

--
Do code for fun.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2018-04-10 13:15:38 Re: [HACKERS] [PATCH] Incremental sort
Previous Message David Steele 2018-04-10 13:07:58 Re: Function to track shmem reinit time