Re: Problemas with gram.y

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-07 10:23:33
Message-ID: 20060307190921.4A6E.ITAGAKI.TAKAHIRO@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message etmorelli 2006-03-07 10:51:14 Re: Problemas with gram.y
Previous Message Martijn van Oosterhout 2006-03-07 09:24:09 Re: Coverity Open Source Defect Scan of PostgreSQL