Appearance
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 first 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.
📌 The hard row count estimate option can be found in:
Data Explorer > Manage > Settings > Table Settings

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.

- Use the sigma symbol (Σ) to calculate the actual row count.
- This will display the actual row count along with a button to update the current hard estimate.
- Pressing the "Update Current Hard Estimate" button opens a confirmation popup, as shown below.

- Use the current hard estimate or enter a value manually.
- Click "YES" to confirm or "NO" to cancel.
- This will overwrite the current hard estimate for the selected table to keep row counts consistent across multiple apps.
💡 It is recommended to update estimates regularly.
💡 To automate updates, use the wpda_set_hard_row_count hook as demonstrated below.
📌 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
<?php
do_action(
'wpda_set_hard_row_count',
'myDatabase',
'myTable'
);
?>