On Wed, Oct 6, 2021 at 1:32 PM Dirschel, Steve <
steve.dirsc...@thomsonreuters.com> wrote:
> Thanks for the reply and the info above. My question was more directed at
> how can you troubleshoot the active session running the query. In the
> examples above you are actually executing the query.
On Wed, Oct 6, 2021 at 12:00 PM Dirschel, Steve <
steve.dirsc...@thomsonreuters.com> wrote:
> Here is what I could see in Postgres:
>
>- When I did an explain on the delete I could see it was full scanning
>the table. I did a full scan of the table interactively in less than 1
>second
On 10/6/21 16:32, Dirschel, Steve wrote:
postgres=# explain (analyze) delete from t; Delete on t
I would try explain (analyze, timing, buffers). That would also give you
the timing of each step so you can figure which one takes the longes.
Regards
--
Mladen Gogala
Database Consultant
On 10/6/21 16:26, Dirschel, Steve wrote:
Thanks for the reply and I hope I’m replying to this e-mail correctly
at the bottom of the chain.
Hey, it's not me, it's rules and regulations. And that's incredibly
important on this group, or so I was lead to believe :)
We are running on AWS
On Wed, Oct 06, 2021 at 06:00:07PM +, Dirschel, Steve wrote:
> • When I did an explain on the delete I could see it was full
scanning the table. I did a full scan of the table interactively in less than 1
second so the long runtime was not due to the full tablescan.
On 10/6/21 14:00, Dirschel, Steve wrote:
Question:
How would one troubleshoot this issue in Postgres as to why the delete was
running so long? My background is Oracle and there are various statistics I
may look at:
· One could estimate the number of logical reads the delete should do
On Wed, 2021-10-06 at 18:00 +, Dirschel, Steve wrote:
> Are there other statistics in Postgres I may have looked at to methodically
> come to the conclusion that the problem was the missing index on the parent
> FK column?
You could use the query from my article to find the missing indexes:
On Wed, Oct 06, 2021 at 06:00:07PM +, Dirschel, Steve wrote:
> • When I did an explain on the delete I could see it was full scanning
> the table. I did a full scan of the table interactively in less than 1 second
> so the long runtime was not due to the full tablescan.
> I started
On 10/6/21 14:00, Dirschel, Steve wrote:
Question:
How would one troubleshoot this issue in Postgres as to why the delete
was running so long? My background is Oracle and there are various
statistics I may look at:
* One could estimate the number of logical reads the delete should
do
Question:
How would one troubleshoot this issue in Postgres as to why the delete was
running so long? My background is Oracle and there are various statistics I
may look at:
• One could estimate the number of logical reads the delete should do
based on expected number of rows to delete,
10 matches
Mail list logo
