From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Jaime Casanova <systemguards(at)gmail(dot)com>, tmorelli(at)tmorelli(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org, etmorelli(at)superig(dot)com(dot)br |
Subject: | Re: Problemas with gram.y |
Date: | 2006-03-08 03:25:06 |
Message-ID: | 200603080325.k283P6O25420@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Patch withdrawn by author for reworking.
---------------------------------------------------------------------------
ITAGAKI Takahiro wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > > CREATE INDEX foo ON bar (x) WITH (fillfactor = 70, option = blah);
> >
> > Yeah, something along this line is what I'd like to see; probably the
> > first form since that creates the least hazard of foreclosing other
> > additions to the syntax later.
>
> > Anyway the bottom line is that we need to put in some infrastructure
> > that can handle multiple index parameters, not a one-off solution that
> > only handles PCTFREE.
>
> Ok, I'll rewrite my PCTFREE patch, and change the word PCTFREE to FILLFACTOR.
> There is no benefit of compatibility with Oracle now.
>
> Current all index access methods (btree, hash and gist) have conception of
> fillfactors, but static bitmap index or something may not have it.
> I see that we should give priority to the design.
>
> ---
> ITAGAKI Takahiro
> NTT Cyber Space Laboratories
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2006-03-08 03:44:17 | Re: Merge algorithms for large numbers of "tapes" |
Previous Message | Jonah H. Harris | 2006-03-08 01:28:17 | Re: Merge algorithms for large numbers of "tapes" |