It used to take longer. Now, after starting up the times are comparable
to pgAdmin3.
*/Patrick Headley/*
Linx Consulting, Inc.
phead...@linxco-inc.com
(303) 916-5522
www.linxco-inc.com
On 06/14/2017 01:29 AM, Mike Surcouf wrote:
A 32 second startup time and a 2-6 seconds to expand each node i
Greetings!
The PostgreSQL Infrastructure team will be migrating the project's
mailing lists from the existing system (an ancient and unmaintained
piece of software called "majordomo2") to a newly developed mailing list
system (known as "PGLister"), which better addresses the needs of the
PostgreSQ
> However, it's the resolver that's slow here.
Given the startup on my chrome browser generates 180 requests to the server
side version (I assume the QTweb version would be the same) I am also hopeful
webpack in combination may help a lot.
180 requests is obviously not good for performance espe
On Wed, Jun 14, 2017 at 4:05 PM, Mike Surcouf wrote:
>> However, it's the resolver that's slow here.
>
> Given the startup on my chrome browser generates 180 requests to the server
> side version (I assume the QTweb version would be the same) I am also
> hopeful webpack in combination may help
Are you listening on ipv6?
Because as mentioned that will create problems as the dns resolver always
returns ::1 on windows
Would it not be better to listen on both version of ip
-Original Message-
From: pgadmin-support-ow...@postgresql.org
[mailto:pgadmin-support-ow...@postgresql.org]
On 14/06/17 15:45, grekloe...@tutanota.com wrote:
I asked, very politely, about the whole situation. I didn't get any
sensible replies at all -- only a bunch of irrelevant, weird nonsense
from people who clearly didn't even read what I had written.
Then somebody else asks a similar question an
I asked, very politely, about the whole situation. I didn't get any sensible
replies at all -- only a bunch of irrelevant, weird nonsense from people who
clearly didn't even read what I had written.
Then somebody else asks a similar question and gets tons of replies, but again,
everyone just ig
On Wed, Jun 14, 2017 at 2:37 PM, Mike Surcouf wrote:
> Are you listening on ipv6?
No, as mentioned it listens on 127.0.0.1.
> Because as mentioned that will create problems as the dns resolver always
> returns ::1 on windows
Yes.
> Would it not be better to listen on both version of ip
Proba
On Wed, Jun 14, 2017 at 2:28 PM, Melvin Davidson
wrote:
> *Regardless of the upcoming problem resolution regarding slow start times,
> or any of the multitude of Reddit reports, I think PgAdmin developers
> should consider this a lesson learned and test on ALL platforms (IE:Mac,
> Windows, Linux)
Regardless of the upcoming problem resolution regarding slow start times, or
any of the multitude of Reddit reports, I think PgAdmin developers should
consider this a lesson learned and test on ALL platforms (IE:Mac, Windows,
Linux) before releasing a new version.
Melvin Davidson 🎸
Cell
On Wed, Jun 14, 2017 at 1:55 PM, Bruno Friedmann wrote:
> On mercredi, 14 juin 2017 10.13:44 h CEST Dave Page wrote:
>> On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf wrote:
>> > Static resources will be good for caching :-) I would expect to see
>> > performance gains when using remotely via a b
On mercredi, 14 juin 2017 10.13:44 h CEST Dave Page wrote:
> On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf wrote:
> > Static resources will be good for caching :-) I would expect to see
> > performance gains when using remotely via a browser. Thankyou. I'm not
> > sure whether QtWeb will benefit
[Yes, I'm on Windows 10]
It does appear that the tool's (or should I say those of the upstream
browser kit / underlying platform) seem to resolve `localhost` very
slowly; it seems about as slow as either a DNS resolver timeout or a
network isn't there. Others mention rewriting the host entry
Static resources will be good for caching :-) I would expect to see
performance gains when using remotely via a browser. Thankyou.
I'm not sure whether QtWeb will benefit as much as its local traffic so round
trips should be pretty instantaneous.
Unless QtWeb is horribly inefficient in which ca
Hi
On Tue, Jun 13, 2017 at 5:52 PM, Shira Bezalel wrote:
> Hi Dave.
>
> On Mon, Jun 12, 2017 at 1:38 AM, Dave Page wrote:
>>
>> Hi
>>
>> On Sun, Jun 11, 2017 at 6:42 PM, Jack Royal-Gordon
>> wrote:
>> > Hi,
>> >
>> > First, I appreciate your tone of constructive criticism — there has been
>> >
On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf wrote:
> Static resources will be good for caching :-) I would expect to see
> performance gains when using remotely via a browser. Thankyou.
> I'm not sure whether QtWeb will benefit as much as its local traffic so round
> trips should be pretty i
On Wed, Jun 14, 2017 at 8:29 AM, Mike Surcouf wrote:
> A 32 second startup time and a 2-6 seconds to expand each node is
> encouraging?
Unless you're on a slow connection, the node expansion time should be
extremely quick the second and subsequent times in a session, and even
then the delay shou
A 32 second startup time and a 2-6 seconds to expand each node is encouraging?
From: pgadmin-support-ow...@postgresql.org
[mailto:pgadmin-support-ow...@postgresql.org] On Behalf Of Patrick Headley
Sent: 14 June 2017 01:23
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin
18 matches
Mail list logo
