It turns out that, at least on pgsql, using an explicit ORDER BY 1 on that UNION query kills performance; pg becomes cpu bound when I start gnus (which ends up doing an EXAMINE on every group).
I've re-worked my proposed patches. The branches: git://people.freedesktop.org/~cloos/dbmail.git for-master git://people.freedesktop.org/~cloos/dbmail.git for-2_2 are now at: 656c84638a75c2d4ea8fb772fcc146a95bf42f90 refs/heads/for-2_2 8bf102e145b0c6f0aa5b43c4a5ba4531a7ff0331 refs/heads/for-master Both patches, matching each branch's existing style, now use the value specified for the first column to determine what the second column represents, rather than assuming that the rows are returned in [exists, seen, recent] order. To facilitate this, the literal column is changed from ['a', 'b', 'c'] to [0, 1, 2] and the exists, seen and recent variables are replaced with an array. It was just dumb luck that the results were previously in the expected order. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
