[RFC PATCH] 3x improvement in patch listing
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...
Size: 228 bytes
Desc: not available
More information about the Patchwork