Mark Felder writes:
Not specifically. I understand the reasoning was due to the
number of full table scans that were occurring as that was
indicated in its output.
Hm.
I suspect that it jumped to the wrong conclusion.
A query such as "fetch all the Subject fields for all messages" would use
such an index, but clients don't do that. They retrieve a hundred messages
or so. 500, maybe.
I just tested Rainloop as an alternative webmail interface and
it doesn't permit me to do any sorting of the mail folders at
all because it detects the IMAP server doesn't have any SORT
capability.
In other words: You really, really want functional SORT.
Yes, because without a client that can download the whole mail
folder or at least the headers and do local sorting it seems
very common for the mails to be randomly sorted when listing the
mail folder contents. I am guessing it's just returning exactly
the order that's in the table? If you delete a bunch of mail
then new mail starts filling in those holes in the existing
table and it gets progressively worse...
If you don't sort, you'll generally get UID order. Each new message in a
folder gets a new UID, higher than any in the folder. Moving a message from
folder A to folder B and back to A allocates an UID in B and then one in A.
Aox is written in such a manner that pg's table order is never visible.
There must necessarily be some sort of sorting inside aox. We made that
invariant for the sake of testing.
Arnt
