|
> The only way I can see for that to be so slow is if you have a very > large number of rows where payment_id is null --- is that the case? The number of rows where payment_id is null is indeed large. They increase every day to about 1 million at the end of the so-called "payment period" (so currently, about 1/100th of the table has nulls). > In 8.3 it'll be possible to declare the index as NULLS FIRST, which > moves the performance problem from the max end to the min end ... Sounds interesting. I also noticed 8.3 is able to use an index for "is null". Luckily you've just released the beta release of 8.3. I'm going to setup a test system for 8.3 real soon then to try what difference it would make for my particular dataset. > Creating indexes at random with no thought about how the system could > use them is not a recipe for speeding up your queries. What you'd need > to make this query fast is a double-column index on (payment_id, time) > so that a forward scan on the items with payment_id = 67 would > immediately find the minimum time entry. Neither of the single-column > indexes offers any way to find the desired entry without scanning over > lots of unrelated entries. I see, that sounds very interesting too. As you might have noticed, I'm not an expert on this field but I'm trying to learn. I was under the impression that the last few incarnations of postgresql automatically combined single column indexes for cases where a multi-column index would be needed in earlier releases. But apparently this isn't true for every case and I still have a lot to learn about PG. Regards Express yourself instantly with MSN Messenger! MSN Messenger |
