Обсуждение: Why is pgadmin so slow to display data on a Mac?

Поиск
Список
Период
Сортировка

Why is pgadmin so slow to display data on a Mac?

От
Tim Uckun
Дата:
PgAdmin extremely slow to display data on a Mac (I haven't tried it on other platforms). I have a Macbook Air 2GHz i7 with eight gigs of ram and of course the SSD drive and yet PgAdmin is painful to use. 

I am almost certain this is due to some problem with rendering results and not fetching the results. The more fields in the result the worse the times get EVEN IF THERE ARE NO ROWS!.

For example if I do a Select * from table where 1=0 the query runs instantly but there is a noticable lag in showing the results. If I do a bunch of joins so that the number of fields grows it takes even longer to display zero rows.

Of course if I have rows the lag is even longer. If for whatever reason one of those rows has a text field with a large amount of data in it then you might as well go have lunch while it's displaying even one row.

Once again this has nothing to do with network lag or speed of queries. The queries run instantly and display instantly if I am using psql. PgAdmin chokes on them though.

Is there anything that can be done about this?

Re: Why is pgadmin so slow to display data on a Mac?

От
"Brett Maton"
Дата:

Which version are you running?

 

  I use pgAdmin3 v. 1.16.1 on an  Air with 4Gb of RAM, OS X 10.7.5 and it works just fine without any noticeable lag.

 

From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Tim Uckun
Sent: 19 April 2013 01:36
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] Why is pgadmin so slow to display data on a Mac?

 

PgAdmin extremely slow to display data on a Mac (I haven't tried it on other platforms). I have a Macbook Air 2GHz i7 with eight gigs of ram and of course the SSD drive and yet PgAdmin is painful to use. 

 

I am almost certain this is due to some problem with rendering results and not fetching the results. The more fields in the result the worse the times get EVEN IF THERE ARE NO ROWS!.

 

For example if I do a Select * from table where 1=0 the query runs instantly but there is a noticable lag in showing the results. If I do a bunch of joins so that the number of fields grows it takes even longer to display zero rows.

 

Of course if I have rows the lag is even longer. If for whatever reason one of those rows has a text field with a large amount of data in it then you might as well go have lunch while it's displaying even one row.

 

Once again this has nothing to do with network lag or speed of queries. The queries run instantly and display instantly if I am using psql. PgAdmin chokes on them though.

 

Is there anything that can be done about this?

Re: Why is pgadmin so slow to display data on a Mac?

От
Dave Page
Дата:
On Fri, Apr 19, 2013 at 7:39 AM, Brett Maton <matonb@ltresources.co.uk> wrote:
> Which version are you running?
>
>
>
>   I use pgAdmin3 v. 1.16.1 on an  Air with 4Gb of RAM, OS X 10.7.5 and it
> works just fine without any noticeable lag.

Yeah, so does everyone at EnterpriseDB (not usually an Air admittedly,
typically Pros).

Do you have debug logging enabled Tim? That can slow things down.

> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Tim Uckun
> Sent: 19 April 2013 01:36
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] Why is pgadmin so slow to display data on a Mac?
>
>
>
> PgAdmin extremely slow to display data on a Mac (I haven't tried it on other
> platforms). I have a Macbook Air 2GHz i7 with eight gigs of ram and of
> course the SSD drive and yet PgAdmin is painful to use.
>
>
>
> I am almost certain this is due to some problem with rendering results and
> not fetching the results. The more fields in the result the worse the times
> get EVEN IF THERE ARE NO ROWS!.
>
>
>
> For example if I do a Select * from table where 1=0 the query runs instantly
> but there is a noticable lag in showing the results. If I do a bunch of
> joins so that the number of fields grows it takes even longer to display
> zero rows.
>
>
>
> Of course if I have rows the lag is even longer. If for whatever reason one
> of those rows has a text field with a large amount of data in it then you
> might as well go have lunch while it's displaying even one row.
>
>
>
> Once again this has nothing to do with network lag or speed of queries. The
> queries run instantly and display instantly if I am using psql. PgAdmin
> chokes on them though.
>
>
>
> Is there anything that can be done about this?



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

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



Re: Why is pgadmin so slow to display data on a Mac?

От
Tim Uckun
Дата:
I am running 1.16.1 OSX 10.8.3

I am using the default config which has the logging set at errors only.

I had a discussion with a couple of other people at the office today and they too reported similar problems (and others).

Are you guys using a local postgres or a remote one? I am usually using a remote one (rackspace) but as I mentioned before If I connect to it using psql I don't have the same problems.  Also the problem with large text fields occurs even when running against a local pg.


Re: Why is pgadmin so slow to display data on a Mac?

От
Alexander Yerenkow
Дата:

Can confirm lag while displaying large text field (few kb), on appearing and scrolling.
Even if there not much rows.
1.16.1, Windows/FreeBSD same behavior.


2013/4/19 Tim Uckun <timuckun@gmail.com>
I am running 1.16.1 OSX 10.8.3

I am using the default config which has the logging set at errors only.

I had a discussion with a couple of other people at the office today and they too reported similar problems (and others).

Are you guys using a local postgres or a remote one? I am usually using a remote one (rackspace) but as I mentioned before If I connect to it using psql I don't have the same problems.  Also the problem with large text fields occurs even when running against a local pg.





--
Regards,
Alexander Yerenkow