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: | Raw Message | Whole Thread | 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 |