[PERFORM] where+orderby+limit not (always) using appropriate index?

Dear Gurus, I don't think it's a bug, I just don't understand what's behind this. If there's a paper or something on this, please point me there. Version: 7.4.6 Locale: hu_HU (in case that matters) Dump: see below sig. Abstract: Create a table with (at least) two fields, say i and o. Create

[PERFORM] Wrong index used when ORDER BY LIMIT 1

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

Re: [PERFORM] Wrong index used when ORDER BY LIMIT 1

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

Re: [PERFORM] Avoiding cartesian product

Dear Virag, AFAIK aggregates aren't indexed in postgres (at least not before 8.1, which indexes min and max, iirc). Also, I don't think you need to exactly determine the trace_id. Try this one (OTOH; might be wrong): select DISTINCT ON (a.trace_id, a.seq_no) -- See below b.gc_minor

Re: [PERFORM] Throwing unnecessary joins away

Dear Tom, Not sure about Otto's exact problem, but he did mention views, and I'd feel more comfortable if you told me that view-based queries are re-planned based on actual conditions etc. Are they? Also, if you find it unlikely (or very rare) then it might be a configurable parameter. If