Merlin Moncure wrote:
> > > The problem with gprof is that I am going to see all the backend
> startup
> > > stuff too, no? Is there a way to get a dump just the run of the
> query?
> >
> > I was sort of lurking on this thread, waiting to see what became of
> it.
> > Did
> > nobody actually come
> > The problem with gprof is that I am going to see all the backend
startup
> > stuff too, no? Is there a way to get a dump just the run of the
query?
>
> I was sort of lurking on this thread, waiting to see what became of
it.
> Did
> nobody actually come to a conclusion on what that "last msec"
On Wed, Mar 10, 2004 at 11:43:48AM -0500, Bruce Momjian wrote:
> The problem with gprof is that I am going to see all the backend startup
> stuff too, no? Is there a way to get a dump just the run of the query?
I was sort of lurking on this thread, waiting to see what became of it. Did
nobody ac
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> If I do a query on localhost with lots of data, I get a small
> time in the log, if I do it over a slow link the time get higher.
> It changes from 1 second to 2 minutes or something.
> So I think it's until the client has received the data.
It'll at leas
Merlin Moncure kirjutas K, 10.03.2004 kell 17:00:
> Bruce Momjian wrote:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
> >
> > Loo
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >>There seems to be a 'PostgreSQL ping' time of about 1-2 ms in best case
> >>conditions which limits the amount of queries you can fire off in 1
> >>second, no matter how simple. In certain rare cases this is something
> >>of a bottleneck. In my p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
>
> Define "normal SELEC
Merlin Moncure wrote:
> Bruce Momjian wrote:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
> >
> > Looking at log_executor_stats,
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am timing small queries, and found that a PREPARE/EXECUTE of
> > "SELECT 1" takes about 1.2ms on my machine. A normal SELECT doesn't
> > take much longer, so I am wondering why a simpler query isn't
> > faster.
>
> log_executor_
Bruce Momjian wrote:
> I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> longer, so I am wondering why a simpler query isn't faster.
>
> Looking at log_executor_stats, I see the following. Execute show
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> longer, so I am wondering why a simpler query isn't faster.
Define "normal SELECT". I can think of plenty o
I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
longer, so I am wondering why a simpler query isn't faster.
Looking at log_executor_stats, I see the following. Execute shows
nothing taking much time, mos
12 matches
Mail list logo
