I prepared a branch that optimizes the database query behind the
'changes_file_url' property.
It stands to reason that it is more optimal because it avoids the
SourcePackagePublishingHistory and the SourcePackageRelease
tables (with 758673 and 459354 rows respectively).
I am not sure how to test/prove that it is more optimal however.
How about landing it and have James use it (via edge). If all goes
well we can close this bug.
Hi there!
I prepared a branch that optimizes the database query behind the
'changes_file_url' property.
It stands to reason that it is more optimal because it avoids the blishingHistory and the SourcePackageRe lease
SourcePackagePu
tables (with 758673 and 459354 rows respectively).
I am not sure how to test/prove that it is more optimal however.
How about landing it and have James use it (via edge). If all goes
well we can close this bug.
----
What follows are some details on the queries..
The old query (http:// pastebin. ubuntu. com/342524/) joins on the following
tables:
LibraryFile Alias, LibraryFileContent, PackageUpload, PackageUploadSo urce, gePublishingHis tory, SourcePackageRe lease
SourcePacka
In contrast, the new query (http:// pastebin. ubuntu. com/342528/) only uses
these tables:
LibraryFile Alias, PackageUpload, PackageUploadSource