| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | AW: AW: AW: [HACKERS] Some notes on optimizer cost estimates |
| Date: | 2000-01-26 12:25:55 |
| Message-ID: | 219F68D65015D011A8E000006F8590C603FDC224@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Based on experience with optimizer improvements across releases of DB
> products (not PostgreSQL, I hastily add), I would be inclined
> to say (from
> bitter experience) that no optimizer is ever truly
> predicatable. The SQL
> programmer has to be given the tools to ensure that a 'bad'
> query can be
> forced to run the same way with each release, and release notes should
> indicate what extra strategies are now available, in case the
> 'bad' query
> can be made better.
Yes, I think syntax to force or disallow a particular index,
choose a join method or order, force/disallow seq scans ...
is sometimes useful.
Even Informix, who always refused to supply such a feature
now has it.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2000-01-26 13:08:44 | RE: Happy column adding (was RE: [HACKERS] Happy column dropping) |
| Previous Message | Ansley, Michael | 2000-01-26 11:10:50 | RE: [HACKERS] --enable-debug |