[RFC PATCH] 3x improvement in patch listing

[Stewart Smith]

Konstantin Ryabitsev <konstantin at linuxfoundation.org> writes:
> On Wed, Aug 08, 2018 at 05:40:06PM +1000, Stewart Smith wrote:
>>There's two main bits that are really expensive when composing the list
>>of patches for a project: the query getting the list, and the query
>>finding the series for each patch.
>
> Stewart:
>
> Thanks for working on this! Do you think this would help with pagination 
> as well? I find that in semi-abandoned projects like 
> https://patchwork.kernel.org/project/qemu-devel/list/ it takes a few 
> seconds to load the list view due to 800+ pages of unprocessed patches.  
> I am currently considering an automated script that would auto-archive 
> patches older than 6 months, but if simply improving pagination times 
> would fix the issue, then I wouldn't need to bother.

I may be accidentally letting people know I know something about
databases again :)

Out of interest, does the kernel.org instance back onto PostgreSQL or
MySQL? I have a bunch of ideas that would quite dramatically improve
performance on MySQL (properly using primary keys to force disk layout
to be sane, rather than the current screw-locality method that Django
enforces). On PostgreSQL, things are a bit different, but it's possible
an occasional ALTER TABLE CLUSTER BY (or whatever the syntax is) could
help a *lot*.

I'm not sure that archiving the patches would help query performance at
all, but I'd have to check it out a bit. The query that Django generates
is certainly.... "interesting".

-- 
Stewart Smith
OPAL Architect, IBM.