Re: Problemas with gram.y

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. +

In response to

Browse pgsql-hackers by date

  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"