How Index Tables Work

This page explains why Fuzzy keeps index tables and what that means for your store. For the settings, see *Keep a large catalog fast*.

The problem index tables solve

A WooCommerce catalog stores product data in a way that is good for managing products, but answering a filter question — "how many black shoes under 100 are in stock?" — can mean scanning a lot of data. On a small store this is fine. As the catalog grows, doing that work on every shopper request gets slow.

What an index table is

An index table is prepared data, shaped for the questions filtering asks. Instead of working everything out from scratch each time, Fuzzy reads from this prepared table. The result is the same, but the store reaches it with far less work per request.

Why it has to be rebuilt

Because the index is a prepared copy, it has to match the real products. After a big change — a bulk import, a mass attribute edit, large price updates — the index can fall behind. Rebuilding it brings the index back in line with the current catalog. This is why counts can look wrong after a big import until the index is rebuilt.

Why counts and sorting still cost something

Even with an index, some work is inherently heavier. Live per-value counts recalculate the most, and random sorting cannot reuse a stable order. On large catalogs these grow fastest, which is why lighter count modes exist and why random sort is used with care at scale.

Where to go next

• How-to: Keep a large catalog fast.
• Explanation: How Fuzzy filtering works.
• Reference: Plugin Settings — Performance.