Actual plan

[ErikEJ]

I see you are using the actual plan, causing SQL Server to actually execute your query - is that deliberate?

(Sometimes executing a query can have side effects) - I see you do the same for Postgres

[Giorgi]

Yes, it was deliberate. I couldn't think of a scenario where a query could have a side effect so I decided to go with it. Can you share some of the examples?

[ErikEJ]

Triggers adding to log tables, performance impact.

[Giorgi]

Triggers on Select?

[ErikEJ]

Sorry, was thinking of SQL audit, nit triggers

[Giorgi]

I guess (or hope) most people don't use a production database when debugging their code and in the dev environment audit probably doesn't need to be turned on.

[Giorgi]

One of the reasons the extension is in preview is to gather feedback from users so if many people request it, I could implement using an estimated plan.

[ErikEJ]

Cool, or make it an option to choose between actual and estimated?

[wertzui]

I would vote for displaying the estimated plan by default and then displaying the actual plan after the user clicks on something, because of the mentioned possible side effects.

[Xhanti]

I agree with your decision for using the actual query plans and your statement that when used under a debugger it is highly unlikely your pointing at production database. Estimated plans have never been very useful when I’ve tried optimising queries, actual queries is my default these days.

[wertzui]

I agree that estimated execution plans are an order of magnitude worse when debugging problems.
However when debugging really hard problems, there is sometimes no way around than connecting to the live database (if your company does not have a hot standby or you want to wait hours to copy the data to another database).

[to11mtm]

One thought to add here; I wonder whether having the option to do an EXPLAIN rather than executing and going through the logs, would be faster for the 'bad' query cases and help lower the frequency of timeouts?

Sure, explain isn't as accurate, buuuut it might be faster.

Not sure if it's feasible with the code (need to look more at the code and understand VS plugins), but I'm wondering whether one could run two threads (one doing the explain, one trying the current method) and if the current way times out but explain finishes, fall back to that... but also will note that being able to show that EXPLAIN is different from actual plan, can be a good hint to developers as well that something is amiss...