Simon Riggs <[EMAIL PROTECTED]> writes:
> This was a response to Itagaki's comment that there may be a class of
> parameter that changes more frequently than that. I can see that we
> might want that, so just trying to plan ahead to
> dynamically/automatically set parameters - I thought you'd be in
On Mon, 2006-06-19 at 09:15 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Looks like we've got a class of data that is similar in its frequency of
> > change to the pg_class_nt stuff.
>
> Say what? These parameters wouldn't ever change after creation, unless
> we invent ALT
Simon Riggs <[EMAIL PROTECTED]> writes:
> Looks like we've got a class of data that is similar in its frequency of
> change to the pg_class_nt stuff.
Say what? These parameters wouldn't ever change after creation, unless
we invent ALTER commands to change them.
regards, t
On Mon, 2006-06-19 at 14:36 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > > 2. Store the structures in AM's meta page. But heaps don't have meta
> > > pages.
> >
> > But perhaps they should? That sounds very similar to the idea of
> > non-transactional pg_class d
Simon Riggs <[EMAIL PROTECTED]> wrote:
> > 2. Store the structures in AM's meta page. But heaps don't have meta pages.
>
> But perhaps they should? That sounds very similar to the idea of
> non-transactional pg_class data.
Presently, I suppose the parameters are not modified so many times.
They
Tom Lane <[EMAIL PROTECTED]> wrote:
> The disadvantage of putting this stuff into metapages is that then you
> need some entirely new protocol for letting clients get at it (and
> pg_dump, for one, needs to).
> An opaque bytea won't do though. What I'd suggest is something real
> close to the fo
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2006-06-16 at 13:33 +0900, ITAGAKI Takahiro wrote:
>> 2. Store the structures in AM's meta page. But heaps don't have meta pages.
> But perhaps they should? That sounds very similar to the idea of
> non-transactional pg_class data.
The disadvantag
On Fri, 2006-06-16 at 13:33 +0900, ITAGAKI Takahiro wrote:
> This is a revised fillfactor patch. It uses WITH syntax and
> we can add new AM specific parameters easily.
Cool. I'll look at that in more detail.
> > So we have a new element of the RelationData struct:
> > void*rd_amopts;
> >
This is a revised fillfactor patch. It uses WITH syntax and
we can add new AM specific parameters easily.
Simon Riggs <[EMAIL PROTECTED]> wrote:
> I see what Tom was driving at with earlier comments. I think we need an
> non-index AM specific patch, so that each AM has its own parameters.
I add
