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).