| From: | Hannu Krosing <hannu(at)tm(dot)ee> | 
|---|---|
| To: | gry(at)ll(dot)mit(dot)edu | 
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: automated index suggestor -- request for comment | 
| Date: | 2002-12-13 17:00:32 | 
| Message-ID: | 1039798832.19813.28.camel@huli | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
I cc'b back to list, hope this is ok?
On Fri, 2002-12-13 at 14:56, george young wrote:
> On 13 Dec 2002 12:05:36 +0000
> Hannu Krosing <hannu(at)tm(dot)ee> wrote:
> 
> > On Fri, 2002-12-13 at 03:22, johnnnnnn wrote:
> > 
> > In worst case you could generate the entries in pg_class table without
> > building the actual index and then drop or rollback when the explain is
> > ready.
> > 
> --> Of course you could just determine all possibly useful indexes and <--
> --> generate then anyhow an then drop them if they were not used ;)    <--
> 
> Why not!  At least for selects, this seems like the ideal.  For insert
> and update, you have to deal with updating the superfluous indexes --
> does the planner include index updating in its work estimates? 
Probably not -  the work should be almost the same (modulo cached status
of index pages) for any plan. 
At least I think we don't optimize the plan for different index access
patterns for updating indexes.
> > For queries
> that use functions in the where clause, you'd have to parse enough to know
> to include indexes on the functions (I know-- the last time I said "all I
> have to do is parse ..." I was really sorry later...).
-- 
Hannu Krosing <hannu(at)tm(dot)ee>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2002-12-13 18:18:40 | Re: Capping CPU usage? | 
| Previous Message | Jean-Luc Lachance | 2002-12-13 16:42:25 | Re: [PERFORM] CLUSTER command |