ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Thank you for applying, but sorry, my patch has some incompletions.
I'm busy reviewing/reworking this patch, and will deal with these items.
> 2. Add a comment on the average FSM request size. Now, the size
> contains not only the size of tupl
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Patch applied. Thanks.
Thank you for applying, but sorry, my patch has some incompletions.
1. A debug code is left. Assert() and if-test are redundant.
2. Add a comment on the average FSM request size. Now, the size
contains not only the size o
Patch applied. Thanks.
Catalog version updated.
---
ITAGAKI Takahiro wrote:
> This is the 3rd revised fillfactor patch.
> Now, AM specific options are stored in pg_class.reloptions as text[].
> Also, some bugs are fixed.
This is the 3rd revised fillfactor patch.
Now, AM specific options are stored in pg_class.reloptions as text[].
Also, some bugs are fixed. It passed all regression tests.
Tom Lane <[EMAIL PROTECTED]> wrote:
> An opaque bytea won't do though. What I'd suggest is something real
> close to the for
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
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> "Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
>> There's 4 shift/reduce conflicts which I believe are caused by having
>> used WITH... did you plan to fix this?
> Thanks for pointing out. I realized it is a confliction between
> WITH OIDS and WITH (opt
"Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
> There's 4 shift/reduce conflicts which I believe are caused by having
> used WITH... did you plan to fix this?
Thanks for pointing out. I realized it is a confliction between
WITH OIDS and WITH (options).
I'll try to treat CreateStmt.hasoids as one o
On 6/6/06, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
On 6/6/06, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> This is a patch for table/index fillfactor control discussed in
> http://archives.postgresql.org/pgsql-hackers/2006-06/msg00175.php
There's 4 shift/reduce conflicts which I believe
On 6/6/06, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
This is a patch for table/index fillfactor control discussed in
http://archives.postgresql.org/pgsql-hackers/2006-06/msg00175.php
There's 4 shift/reduce conflicts which I believe are caused by having
used WITH... did you plan to fix thi
On Tue, 2006-06-06 at 18:02 +0900, ITAGAKI Takahiro wrote:
> This is a patch for table/index fillfactor control
This is a good new feature and I'll vote for it.
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 paramet
This is a patch for table/index fillfactor control discussed in
http://archives.postgresql.org/pgsql-hackers/2006-06/msg00175.php
Fillfactor works on CREATE, INSERT, UPDATE, COPY, VACUUM FULL, CLUSTER
and REINDEX, but is not done on dump/restore and GIN access method;
I'd like to ask those modu
19 matches
Mail list logo
