Re: [PATCHES] table/index fillfactor control, try 3

2006-07-02 Thread ITAGAKI Takahiro
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 of tuples, but also freespace on pages.

Especially, there may be a room to discuss on 2; it changed the meaning of
'average request size'. If it is enough only to add a comment, please apply
the following fixes.



diff -cpr pgsql-orig/src/backend/access/heap/hio.c 
pgsql/src/backend/access/heap/hio.c
*** pgsql-orig/src/backend/access/heap/hio.cMon Jul  3 09:22:49 2006
--- pgsql/src/backend/access/heap/hio.c Mon Jul  3 10:22:40 2006
*** RelationGetBufferForTuple(Relation relat
*** 108,115 
otherBlock;
boolneedLock;
  
-   if (relation-rd_options == NULL)
-   elog(ERROR, RelationGetBufferForTuple %s IS NULL, 
RelationGetRelationName(relation));
Assert(relation-rd_options != NULL);
  
len = MAXALIGN(len);/* be conservative */
--- 108,113 
diff -cpr pgsql-orig/src/backend/storage/freespace/freespace.c 
pgsql/src/backend/storage/freespace/freespace.c
*** pgsql-orig/src/backend/storage/freespace/freespace.cMon Jul  3 
09:22:50 2006
--- pgsql/src/backend/storage/freespace/freespace.c Mon Jul  3 10:30:26 2006
*** RecordAndGetPageWithFreeSpace(RelFileNod
*** 341,346 
--- 341,348 
  /*
   * GetAvgFSMRequestSize - get average FSM request size for a relation.
   *
+  * Retuened value is the average of item size plus freespace specified
+  * by fillfactor.
   * If the relation is not known to FSM, return a default value.
   */
  Size

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [PATCHES] table/index fillfactor control, try 3

2006-07-02 Thread Tom Lane
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 tuples, but also freespace on pages.

Yeah, I noticed this and thought it was probably a pretty bad idea:
it plays hob with the notion of tracking a moving average of freespace
requests.  I'm not sure what else to do though.  Do we want the FSM to
explicitly account for fillfactor, and if so how exactly?  There's
certainly no point in returning a page that doesn't have space for the
fillfactor padding.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] table/index fillfactor control, try 3

2006-07-01 Thread Bruce Momjian

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. 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 format used for GUC parameters in ALTER DATABASE SET and
  ALTER USER SET, ie, pairs of keyword/value strings.  This way pg_dump
  doesn't need very much smarts about what the values are that it's
  dumping.
 
 The column format of options is changed from bytea to an array of text,
 so re-parsing is needed every time a connection accesses a relation.
 I changed to write pre-parsed options into pg_internal.init, but AFAICS,
 only system relations are written in it. If we will find the parsing
 is slow, it might be good to store options for user relations, too.
 
 
 Regards,
 ---
 ITAGAKI Takahiro
 NTT Open Source Software Center

[ Attachment, skipping... ]

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org