Dear Tom,
On 2005.12.21. 20:34, Tom Lane wrote:
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= [EMAIL PROTECTED] writes:
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
Much the best solution for this would be to have an index on
(muvelet, idopont)
--- perhaps you can reorder
Dear Gurus,
Version: 7.4.6
I use a query on a heavily indexed table which picks a wrong index
unexpectedly. Since this query is used in response to certain user
interactions thousands of times in succession (with different constants),
500ms is not affordable for us. I can easily work around
On Wed, Dec 21, 2005 at 07:03:00PM +0100, Sz?cs Gbor wrote:
Version: 7.4.6
[...]
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
I expected the planner to choose the index on muvelet, then sort by idopont.
Instead, it took the other index.
I think the planner is
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= [EMAIL PROTECTED] writes:
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
Much the best solution for this would be to have an index on
(muvelet, idopont)
--- perhaps you can reorder the columns of muvelet_vonalkod_muvelet
instead of
