| From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Index Tuning Features |
| Date: | 2006-10-11 09:54:25 |
| Message-ID: | 1160560464.19368.88.camel@coppola.muc.ecircle.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> The above process can be performed without tool support, but its clear
> that further automation will help greatly here. I foresee that the
> development of both server-side and tools will take more than one
> release. Discussion of tool support can begin once we have agreed
> server-side capability.
If it came to automated tools, wouldn't fit in this discussion to give
some performance requirement limits to the RECOMMEND tool ? In a
workload not all queries are real time or high priority, and such a
lesser impact index can help enough sometimes to meet the requirements,
compared to a high impact index which would make the query fly.
Example: inserting in a table must be real time, reporting can be taken
offline...
So it would be nice to have a recommendation tool which can take into
account the performance requirements of the individual queries, possibly
making the right compromises to meat all requirements for all queries.
Cheers,
Csaba.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Woodward | 2006-10-11 11:21:57 | Re: Index Tuning Features |
| Previous Message | Simon Riggs | 2006-10-11 09:41:41 | Re: Index Tuning Features |