Performance improvement due to SQL hack
Performance improvement due to SQL hack

This hacks around a silly postgres plan by moving the LIMIT operation
from SQL to python... see inline comment.

Slow performance hit me for values of OFFSET > 200 and values of LIMIT <
600 on my particular test data set and so this was not apparent until
pagination was implemented and we actually had an offset.

Have tried it out together with the automagic pagination (see issue #4)
and it seems to be working fairly well.

garberg/NIPAP,garberg/NIPAP,bbaja42/NIPAP,plajjan/NIPAP,bbaja42/NIPAP,SpriteLink/NIPAP,fredsod/NIPAP,SoundGoof/NIPAP,SpriteLink/NIPAP,SoundGoof/NIPAP,SoundGoof/NIPAP,SpriteLink/NIPAP,fredsod/NIPAP,SoundGoof/NIPAP,fredsod/NIPAP,fredsod/NIPAP,garberg/NIPAP,plajjan/NIPAP,SpriteLink/NIPAP,ettrig/NIPAP,ettrig/NIPAP,SoundGoof/NIPAP,plajjan/NIPAP,plajjan/NIPAP,ettrig/NIPAP,bbaja42/NIPAP,garberg/NIPAP,ettrig/NIPAP,ettrig/NIPAP,garberg/NIPAP,plajjan/NIPAP,SpriteLink/NIPAP,garberg/NIPAP,fredsod/NIPAP,bbaja42/NIPAP,SoundGoof/NIPAP,fredsod/NIPAP,SpriteLink/NIPAP,ettrig/NIPAP,bbaja42/NIPAP,bbaja42/NIPAP,plajjan/NIPAP