[RFC PATCH] 3x improvement in patch listing
stewart at linux.ibm.com
Thu Aug 9 11:55:16 AEST 2018
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.
> 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".
OPAL Architect, IBM.
More information about the Patchwork