Order Status Performance Issues

I’ve reviewed the code involved order status change from awaiting percription to dispensing ,
I found that this process attached logged in admin prescriber id to customer order and based on that details pdf invoice get signature and other details like registration etc.
This process involved to update postmeta table that currently has 9 gb records
I think attacing prescriber id in this process takes time update in postmeta table due its scans large numbe of data every single update query.

Above may the reason for slowing down website at this operation
I’ve also tried manuall sql auery to update perscriberd id to selected orders but thats not help to reduce execution time as it takes same sql query.

Also We have checked pdf invoice plugin and its setting and found that it is correctly setup.

Also when I running this operation I found that query monitor shows some gravity form slow queries also running in this process, I am unable to find out why gravity form query runs at this time.
and you know we have reverted back to older version of gravity after upgradtion at live because newer version causes validation not work at front end consultation.
I we shoould also update gravity form , mailchimp plugins to latest version.
First I’ll update gravity form , mailchimp to our demo server and then I’ll check entire process again to see if it improved or not

If above not work then our last option is to reduce postmeta table archive older orders to seperated table to reduce server overload

Make above more improved way

Here's a more refined version of your analysis and plan:

—

I've reviewed the code handling the order status change from **"Awaiting Prescription"** to **"Dispensing"** and found that this process attaches the **logged-in admin prescriber ID** to the customer order. This ID is then used to generate a **PDF invoice**, including the prescriber's **signature, registration details, and other information**.

### **Findings & Observations:**

1. **Performance Impact Due to Large `postmeta` Table:**
– The update process modifies the `postmeta` table, which currently holds **9GB of data**.
– Each update query scans a large number of records, leading to slow execution times.
– Running the same SQL update manually confirms that the update itself is time-consuming.

2. **PDF Invoice Plugin & Settings:**
– Checked and confirmed that the plugin is correctly configured.

3. **Unexpected Gravity Forms Queries:**
– While executing the order status change, **Query Monitor** indicates slow queries from **Gravity Forms**.
– It's unclear why Gravity Forms queries are triggered during this process.
– We previously **reverted to an older version of Gravity Forms** on the live site due to validation issues in frontend consultations.

4. **Next Steps:**
– **Update Gravity Forms & Mailchimp Plugins** on the **demo server** first.
– Re-test the entire process to check if performance improves.

5. **Final Option – Postmeta Table Optimization:**
– If the issue persists, we should consider **archiving older orders** into a **separate table** to reduce server overload.

—

This approach ensures a structured troubleshooting process, minimizing risk while aiming for performance improvements. Let me know if you need any refinements! 🚀

remove bold

Here's a refined version without bold formatting:

—

I've reviewed the code handling the order status change from "Awaiting Prescription" to "Dispensing" and found that this process attaches the logged-in admin prescriber ID to the customer order. This ID is then used to generate a PDF invoice, including the prescriber's signature, registration details, and other information.

### Findings & Observations:

1. **Performance Impact Due to Large `postmeta` Table:**
– The update process modifies the `postmeta` table, which currently holds 9GB of data.
– Each update query scans a large number of records, leading to slow execution times.
– Running the same SQL update manually confirms that the update itself is time-consuming.

2. **PDF Invoice Plugin & Settings:**
– Checked and confirmed that the plugin is correctly configured.

3. **Unexpected Gravity Forms Queries:**
– While executing the order status change, Query Monitor indicates slow queries from Gravity Forms.
– It's unclear why Gravity Forms queries are triggered during this process.
– We previously reverted to an older version of Gravity Forms on the live site due to validation issues in frontend consultations.

4. **Next Steps:**
– Update Gravity Forms & Mailchimp Plugins on the demo server first.
– Re-test the entire process to check if performance improves.

5. **Final Option – Postmeta Table Optimization:**
– If the issue persists, we should consider archiving older orders into a separate table to reduce server overload.

—

This approach ensures a structured troubleshooting process, minimizing risk while aiming for performance improvements. Let me know if you need any refinements!