Jake Howard

Merged in 76fb103f5489757f647bca44adf4640eb300f99d, thanks!

The complexity is my biggest concern from this too. `.values` might work if we can get the column names setup correctly. I'll have a play and see.

I've tweaked the implementation to avoid diving too deep into Django internals, and without notably impacting performance. This sacrifices support for `.only`, but as that's also missing from the `defer=False`...

> improve things even further with `values_list(named=True)` That's a fairly large change. Most use cases of `specific_deferred` are likely to be "Give me an instance of my page with the...

Annotations and `prefetch_related` works. Django however silently discards `select_related` preferences when using `.values` (and `.values_list` for that matter), so it's not possible. There's no error, it's just that the model...

This optimisation sadly breaks `select_related`. Therefore, in `select_related` cases, we'll fall back to the previous implementation to ensure backwards compatibility. Since it's only an internal implementation detail, there's no need...

The cause of the slowdown seems to be related to the use of `.specific(defer=True)`. As this is the main optimisation, I'll do some digging as to why it's so much...

The issue is indeed from `.specific(defer=True)`, particularly when used as a queryset (as opposed to a singular use of `.specific_deferred`). I have a rough fix, but it'll pollute this PR...

Regardless, you still need to generate the sitemap at some point, which is clearly a performance issue currently, regardless of _when_ you generate it. Spending some time trying to optimise...

I've done some testing on this, and in the 10 years since this issue was created, both Wagtail and Django have come along way. Testing a sitemap with ~10000 items...