[RFC PATCH] 3x improvement in patch listing

Konstantin Ryabitsev konstantin at linuxfoundation.org
Fri Aug 10 00:24:14 AEST 2018

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

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.

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

More information about the Patchwork mailing list