Thread: Graphical Query Builder enable/disable switch (or confirmation dialog)

It would be really nice to make it possible to add a possibility to
disable the usage of 'Graphical Query Builder' (or at least add an
additional confirmation dialog before switching to this mode)

The problem is, that when Graphical Query Builder is trying to fetch
schemas and tables for that current connection, that is very slow for
databases with large amount of tables and schemas.

--  Valentine Gogichashvili


On Wed, Apr 8, 2009 at 12:54 PM, valgog <valgog@gmail.com> wrote:
> It would be really nice to make it possible to add a possibility to
> disable the usage of 'Graphical Query Builder' (or at least add an
> additional confirmation dialog before switching to this mode)
>
> The problem is, that when Graphical Query Builder is trying to fetch
> schemas and tables for that current connection, that is very slow for
> databases with large amount of tables and schemas.

If you don't want to use the GQB, then don't click the tab.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com


Hi,

When you accidentally click on the scary tab (I managed to do it twice
already) the whole pgAdmin is blocked for more then 3 minutes. It is
not normal not to ask for a confirmation before some long lasting
operation (especially when the button to start this operation locates
directly under most used buttons on the toolbar).

And why not to add the enable/disable switch? There is a possibility
to control which elements types are to be shown in the object tree.

With best regards,

-- Valentine Gogichashvili

On Apr 8, 1:59 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Apr 8, 2009 at 12:54 PM, valgog <val...@gmail.com> wrote:
> > It would be really nice to make it possible to add a possibility to
> > disable the usage of 'Graphical Query Builder' (or at least add an
> > additional confirmation dialog before switching to this mode)
>
> > The problem is, that when Graphical Query Builder is trying to fetch
> > schemas and tables for that current connection, that is very slow for
> > databases with large amount of tables and schemas.
>
> If you don't want to use the GQB, then don't click the tab.
>
> --
> Dave Page
> EnterpriseDB UK:  http://www.enterprisedb.com
>
> --
> Sent via pgadmin-support mailing list (pgadmin-supp...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgadmin-support



On Wed, Apr 8, 2009 at 1:38 PM, valgog <valgog@gmail.com> wrote:
> Hi,
>
> When you accidentally click on the scary tab (I managed to do it twice
> already) the whole pgAdmin is blocked for more then 3 minutes. It is
> not normal not to ask for a confirmation before some long lasting
> operation (especially when the button to start this operation locates
> directly under most used buttons on the toolbar).

How big is your database? Even with 5000+ tables it only takes a
minute on my laptop. We're aware that code needs some redesign, but I
wasn't aware it was that bad except in a tiny minority of cases. Maybe
we need to bring forward the proposed rewrite.

> And why not to add the enable/disable switch? There is a possibility
> to control which elements types are to be shown in the object tree.

That controls what elements of the database are displayed. It doesn't
enable or disable entire features.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com


On Apr 8, 3:01 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Apr 8, 2009 at 1:38 PM, valgog <val...@gmail.com> wrote:
> > Hi,
>
> > When you accidentally click on the scary tab (I managed to do it twice
> > already) the whole pgAdmin is blocked for more then 3 minutes. It is
> > not normal not to ask for a confirmation before some long lasting
> > operation (especially when the button to start this operation locates
> > directly under most used buttons on the toolbar).
>
> How big is your database? Even with 5000+ tables it only takes a
> minute on my laptop. We're aware that code needs some redesign, but I
> wasn't aware it was that bad except in a tiny minority of cases. Maybe
> we need to bring forward the proposed rewrite.

Are you testing your local database or you are connected to the remote
one? I am connected to the my database (about 3000 tables) using an
SSH tunel. I can imagine, that transferring all the table data from
the remote database to the client machine takes all the time (in case
it works fast for the local databases of a big size)

>
> > And why not to add the enable/disable switch? There is a possibility
> > to control which elements types are to be shown in the object tree.
>
> That controls what elements of the database are displayed. It doesn't
> enable or disable entire features.
>

My suggestion was also not the disable the feature completely. Making
it possible to hide it from the interface is completely sufficient.

Even a simple confirmation dialog before trying to fetch all the table
information from the database would solve the problem of people who
miss the button to often, like I do.

Actually the request about the slowness of the switching between
databases in Query window is much, much more important in our case (as
we switch from standby and live databases quite often having one file
open in the Query window). I can imagine, that this slowness is
directly related to some 'optimizations' for GQB.

regards,

-- Valentine Gogichashvili


On Wed, Apr 8, 2009 at 2:16 PM, valgog <valgog@gmail.com> wrote:

> Actually the request about the slowness of the switching between
> databases in Query window is much, much more important in our case (as
> we switch from standby and live databases quite often having one file
> open in the Query window). I can imagine, that this slowness is
> directly related to some 'optimizations' for GQB.

I've committed a (fairly large) change that causes the GQB to only
load the table details if a schema node is double-clicked. This means
that if you click on the GQB tab by mistake it won't try to load
details of all your tables.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com