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 to a conclusion
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
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 was
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 shows
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_stats output
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, I see the
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 SELECT. I can
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 personal case
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.
Looking at
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 least be
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,
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 of people
12 matches
Mail list logo
