[RFC PATCH] 3x improvement in patch listing

[Konstantin Ryabitsev]

On Thu, Aug 09, 2018 at 11:55:16AM +1000, Stewart Smith wrote:
>Out of interest, does the kernel.org instance back onto PostgreSQL or
>MySQL? 

We have one of each. The original instance patchwork.kernel.org is on 
MySQL (well, MariaDB), because that's the database cluster we have in 
our PDX DC. When we split the LKML project off to a VM in AWS 
(lore.kernel.org/patchwork), we set up a separate instance that's backed 
by the AWS PostgreSQL instance. However, that instance is for archival 
purposes only, and the one that's actually used for patch tracking and 
management is patchwork.kernel.org.

>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*.

If you want to recreate a huge project, you can feed 20 years of LKML 
archives into it. :) 

>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".

I know for a fact that it does, because I have empirical evidence to 
prove it. Go to lore.kernel.org/patchwork and try the patch listing with 
Archived=No and without it. There will be a few seconds difference.

-K
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20180809/73312a74/attachment.sig>