Performance

Server-Side versus Client-Side Processing

⚙️ Server-Side Processing

With server-side processing enabled, the browser sends a request to the server each time the table is redrawn (e.g., during pagination, searching, or sorting). This method is recommended for medium to large tables as it significantly improves performance by only transferring the necessary data for each view.

⚙️ Client-Side Processing

Client-side processing loads the entire dataset into the browser in a single request. All subsequent operations like sorting, searching, and pagination are handled locally without contacting the server. This method is optimal for smaller tables as it provides a very responsive user experience after the initial load.

Large Table Support

Configure how the plugin handles data retrieval to optimize for either accuracy or speed.

Requires server-side processing to be enabled. Has no effect when client-side processing is active.

✅ Disable large table support: Get an accurate row count and full pagination.
✅ Enable large table support: Boost performance for large tables.
✅ Let the server decide (default): Automatically enables large table support if rows > 40,000.

⚙️ Behavior with Large Table Support Disabled

Performs a full row count on every query.

• Improved User Experience:
  • Accurate row count.
  • Full set of pagination buttons.
  • Instant search (no need to press Enter).
• Might result in a higher network traffic and server load.

⚙️ Behavior with Large Table Support Enabled

Performance for large tables is enhanced by enabling this feature.

• Uses row count estimation instead of full counts.
• Requires users to press Enter to initiate a search.
• Sets pagination to a compact mode.
• Removes the Last Page pagination button.
• Reduces network traffic and server load.
• Can dramatically boost performance for very large tables.
• Results in poorer user feedback:
  • No row count is displayed.
  • The Last Page pagination button is removed.

⚙️ Default Behavior

Behavior depends on row count.

• Automatically enables large table support if rows > 40,000 using a DBMS estimate.
• Disables large table support otherwise.

⚙️ Use Hard Estimate

Uses a hardcoded row count estimate. Only available when large table support is enabled.

• Skips all row counts, including row count estimation.

A hard estimate can result in a more accurate row count than a DBMS estimation, while still skipping the row count and boosting performance. To use this feature, a hard estimate must be defined in the Data Explorer. If no hard estimate is defined in the Data Explorer, the feature is disabled as demonstrated in the screenshot below.

Once a hard estimate is entered in the Data Explorer, the feature becomes available in the Table Builder. The screenshot below shows a table that contains more than 12.5 million rows with a hard row count estimate. The table performs fast on table load, filter updates, and pagination updates.

A hard estimate must be defined within the Data Explorer under Table Settings.

💡 It is recommended to update estimates regularly.
💡 To automate updates, use the wpda_set_hard_row_count hook.

📌 Notes

• Changes take effect after the next page load.

✨ How to Use Hook wpda_set_hard_row_count

The wpda_set_hard_row_count hook can be used to update the hard row count of specific tables at regular intervals. Execution requires admin privileges. You can call this hook from your own PHP code on the server.

<?php
do_action(
	'wpda_set_hard_row_count',
	'myDatabase',
	'myTable'
);
?>