Обсуждение: Bug in the graphical explain

Ashesh; do we have any capacity in the team to spend a little time on
this at the moment? It'll affect the PEM SQL Profiler as well of
course...

On Thu, Jul 18, 2013 at 9:26 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Hi,
>
> I have no idea on how to fix this. I've attached the test case to
> reproduce it.
>
> First execute the test SQL file, then select the last UPDATE query, and
> hit F7. The graphical explain is kinda ugly because two nodes are one on
> the other. That's not the first time I meet this bug. For example, when
> you explain an DELETE query on a table with foreign keys.
>
> If you know how to fix this, that would be great because I'm completely
> lost here.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>

> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Works nicely - not entirely sure I understand how, but it does the job!!

Nice work - committed.

Thanks!

On Tue, Aug 20, 2013 at 8:15 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Fri, Jul 19, 2013 at 1:58 AM, Dave Page <dpage@pgadmin.org> wrote:

Ashesh; do we have any capacity in the team to spend a little time on
this at the moment? It'll affect the PEM SQL Profiler as well of
course...

First of all apology for very late reply.

Here is the patch which resolves this problem.

On Thu, Jul 18, 2013 at 9:26 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Hi,
>
> I have no idea on how to fix this. I've attached the test case to
> reproduce it.
>
> First execute the test SQL file, then select the last UPDATE query, and
> hit F7. The graphical explain is kinda ugly because two nodes are one on
> the other. That's not the first time I meet this bug. For example, when
> you explain an DELETE query on a table with foreign keys.
>
> If you know how to fix this, that would be great because I'm completely
> lost here.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>

> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

 

http://www.linkedin.com/in/asheshvashi

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Aug 20, 2013 at 1:15 PM, Dave Page <dpage@pgadmin.org> wrote:

Works nicely - not entirely sure I understand how, but it does the job!!

:-)

The position of the shapes were calculated based on the root-shape.

As we do have multiple plans in a single explain query, the position of the shapes of the start from the same position (as the root-shape).

I have created an empty root-shape, which holds all the start level shapes, and helps to determine and differentiate the position of those shapes.

Nice work - committed.

Thanks 

Thanks!

On Tue, Aug 20, 2013 at 8:15 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Fri, Jul 19, 2013 at 1:58 AM, Dave Page <dpage@pgadmin.org> wrote:

Ashesh; do we have any capacity in the team to spend a little time on
this at the moment? It'll affect the PEM SQL Profiler as well of
course...

First of all apology for very late reply.

Here is the patch which resolves this problem.

On Thu, Jul 18, 2013 at 9:26 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Hi,
>
> I have no idea on how to fix this. I've attached the test case to
> reproduce it.
>
> First execute the test SQL file, then select the last UPDATE query, and
> hit F7. The graphical explain is kinda ugly because two nodes are one on
> the other. That's not the first time I meet this bug. For example, when
> you explain an DELETE query on a table with foreign keys.
>
> If you know how to fix this, that would be great because I'm completely
> lost here.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>

> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

 

http://www.linkedin.com/in/asheshvashi

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

 

http://www.linkedin.com/in/asheshvashi

On Tue, 2013-08-20 at 08:58 +0100, Dave Page wrote:
> On Tue, Aug 20, 2013 at 8:57 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com
> > wrote:
>
> > On Tue, Aug 20, 2013 at 1:15 PM, Dave Page <dpage@pgadmin.org> wrote:
> >
> >> Works nicely - not entirely sure I understand how, but it does the job!!
> >>
> > :-)
> >
> > The position of the shapes were calculated based on the root-shape.
> > As we do have multiple plans in a single explain query, the position of
> > the shapes of the start from the same position (as the root-shape).
> > I have created an empty root-shape, which holds all the start level
> > shapes, and helps to determine and differentiate the position of those
> > shapes.
> >
>
> Ah, OK - thanks for the explanation.
>

And a really clever trick. I'm impressed. Thanks, Ashesh.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com