You're right it's an issue.

I've thought about having a fake query builder for instances like these where we know there will be zero results.

Since we know your field is empty, there's zero reason for us to perform a query at all. The only reason we do is so you consistently get a query builder instance when using the field on the frontend.

Thanks for the clarification about the fake query builder. I have a follow-up question regarding Stache behavior:

Since Stache watches file modifications and builds indexes, could this empty field issue be causing unnecessary full index regeneration on initial page load after cache clear when page contains empty field?

Specifically, I'm concerned that when the system queries ALL collections (due to empty field), it might trigger Stache to:

1. Scan all content files
2. Build indexes for all collections
3. Cache more data than necessary

This is particularly critical for our production site with approximately 4-5 thousand entries. I'm observing significant performance impact when opening a page with such field, as it seems to cause complete index regeneration instead of selective updates.

What's also puzzling is that running 'php please stache:warm' doesn't seem to resolve this issue. Shouldn't this CLI command prepare all necessary indexes upfront and prevent such regeneration on page load?

Is this assumption correct about the indexing behavior? If so, would the proposed fake query builder solution prevent this excessive Stache indexing, and why doesn't the warm command help in this case?

could this empty field issue be causing unnecessary full index regeneration

Yes. Any fields involved in the query would cause its index to be generated if it isn't already.

What's also puzzling is that running 'php please stache:warm' doesn't seem to resolve this issue. Shouldn't this CLI command prepare all necessary indexes upfront and prevent such regeneration on page load?

Not every field has an index generated in here. Just known ones like slug, uri, title, etc. You can add more in config/statamic/stache.php, though.

https://statamic.dev/stache#configuring-additional-indexes

If so, would the proposed fake query builder solution prevent this excessive Stache indexing

The idea would be that a query doesn't actually happen, so yes it should bypass any actual work.

Not every field has an index generated in here. Just known ones like slug, uri, title, etc. You can add more in config/statamic/stache.php, though.

https://statamic.dev/stache#configuring-additional-indexes

Thanks for the explanation. One more clarification about indexing configuration:

I've configured additional indexes in config/statamic/stache.php, but they seem to be created for ALL collections. Is there a way to configure field indexes for specific collections only?

For example, if I have a 'city' field that's only used in 'locations' collection, can I limit its index generation to just that collection instead of indexing this field across all collections?

This would help optimize the indexing process since not all fields are used in every collection.

No, at the moment they are across all collections, but they could probably be made more granular.

Thank you for all the detailed explanations! This really helps to understand the Stache behavior better.

Since both issues (empty field queries and collection-wide indexing) can significantly impact performance on larger sites, is there any timeline for implementing these improvements? Specifically:

1. The fake query builder solution for empty fields
2. More granular collection-specific indexing

Would be great to know if these are planned for any upcoming releases.

Nothing is planned yet since both issues were only brought up today. 😄

I'd like to ask one more question regarding Stache index generation in Statamic.
Am I understanding correctly that if there's a link in the navigation to one of the entries from a blog collection that contains 3000 entries, it will trigger index generation for the entire blog collection? In other words, will it generate indexes for all 3000 entries on first page load?

Yes

Thank you for the explanations, I'll be waiting for updates

Hi, I also experience such problems on my projects, please tell me when to wait for the update ?

@jasonvarga Hi, are there any updates on this issue?

@chprof #11184