> I don't think so, unless you define a multicolumn index on those
> specific expressions.
>
> Why the different ordering? What are you doing?
here's what we currently need it for (simplified):
the movie schedules for theatres normally contains the information
theater_id, screen_date, screen_time, screen_number, movie_name and should
be outputed accordingly. it now happens to have some cinema multiplex owners
who for some reasons do not want to publish the screen_number to the
public - but the internal data we receive does contain that information.
thus, for all mulitplex theatres that do not want to publish screen number
information, the data must be ordered by theater_id, screen_date,
screen_time, movie_name.
SELECT * FROM schedule
ORDER BY theater_id,
screen_date,
screen_time,
CASE WHEN no_screennumber THEN NULL ELSE screen_number END,
movie_name;
the (simplyified) query does that just fine... here the loss of indexing
doesn't matter that much as the screen numbers are only in a small range and
thus a seqscan probably as fast as an indexscan.
but there are other more complex queries needing the similar logic with
multiple fields involved, that probably might suffer some performance loss.
i haven't touched the more complex ones yet, but still was wondering if
there might be some performance problems - the realtime queries take quite
long already due to some other non-optimized tables so i wouldn't want to
make this even worse before i had a chance to optimize them ;-)
cheers,
thomas
