esql.org
> *Sent:* Thursday, December 8, 2011 9:48 AM
>
> *Subject:* Re: [PERFORM] Response time increases over time
>
> I have moved the data directory (xlog, base, global, and everything) to an
> ext4 file system. The result hasn't changed unfortuately. With the same
&g
] Response time increases over time
I have moved the data directory (xlog, base, global, and everything) to an ext4
file system. The result hasn't changed unfortuately. With the same load test
the average response time: 80ms; from 40ms to 120 ms everything occurs.
This ext4 has default settin
I have moved the data directory (xlog, base, global, and everything) to an
ext4 file system. The result hasn't changed unfortuately. With the same
load test the average response time: 80ms; from 40ms to 120 ms everything
occurs.
This ext4 has default settings in fstab.
Have you got any other idea w
On Thu, Dec 8, 2011 at 06:37, Aidan Van Dyk wrote:
> Let me guess, debian squeeze, with data and xlog on both on a single
> ext3 filesystem, and the fsync done by your commit (xlog) is flushing
> all the dirty data of the entire filesystem (including PG data writes)
> out before it can return...
Yes, ext3 is the global file system, and you are right, PG xlog and data
are on this one.
Is this really what happens Aidan at fsync?
What is be the best I can do?
Mount xlog directory to a separate file system?
If so, which file system fits the best for this purpose?
Should I also mount the data s
On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó
wrote:
> So there seems to be something on this Debian machine that hinders
> PostgreSQL to perform better. With 8.4 I logged slow queries (with 9.1 not
> yet), and almost all were COMMIT, taking 10-20-30 or even more ms. But at
> the same time the
Thanks for that Mario, I will check it out.
@All:
Anyway, I have compiled 9.1.2 from source, and unfortunately the
performance haven't got better at the same load, it is consistently quite
low (~70 ms average transaction time with 100 clients) on this Debian. I am
quite surprised about this, it is
On 12/07/2011 09:23 AM, Havasvölgyi Ottó wrote:
> Thanks, Josh.
> The only reason I tried 8.4 first is that it was available for Debian as
> compiled package, so it was simpler for me to do it. Anyway I am going
> to test 9.1 too. I will post about the results.
>
If you're using squeeze, you can
Thanks, Josh.
The only reason I tried 8.4 first is that it was available for Debian as
compiled package, so it was simpler for me to do it. Anyway I am going to
test 9.1 too. I will post about the results.
Best reagrds,
Otto
2011/12/7 Josh Berkus
> On 12/6/11 4:30 PM, Havasvölgyi Ottó wrote:
>
On 12/6/11 4:30 PM, Havasvölgyi Ottó wrote:
> Is there so much difference between 8.4 and 9.1, or is this something else?
> Please tell me if any other info is needed.
It is fairly likely that the difference you're seeing here is due to
improvements made in checkpointing and other operations made
Hi all,
I am running a load simulation on Debian with PostgreSQL 8.4.9 (standard
Debian package).
Certain number of clients do the following stepsin a transaction (read
commited level) periodically (about 1.1 transaction per second / client)
and concurrently:
-reads a record of table Machine a
Do not use setString() method to pass the parameter to the
PreparedStatement in JDBC. Construct an SQL query string as you write
it here and query the database with this new SQL string. This will
make the planner to recreate a plan every time for every new SQL
string per session (that is not usuall
The thing to remember here is that prepared statements are only planned once
and strait queries are planned for each query.
When you give the query planner some concrete input like in your example
then it will happily use the index because it can check if the input starts
with % or _. If you use
2008/2/25, Pavel Rotek <[EMAIL PROTECTED]>:
> I have created functional index table(lower(href) varchar_pattern_ops)
> because of lower case "like" searching. When i ask the database directly
> from psql, it returns result in 0,5 ms, but when i put the same command via
> jdbc driver, it returns i
Hi all,
i have strange problem with performance in PostgreSQL (8.1.9). My problem
shortly:
I'm using postgreSQL via JDBC driver (postgresql-8.1-404.jdbc3.jar) and
asking the database for search on table with approximately 3 000 000
records.
I have created functional index table(lower(href)
On Wed, Nov 05, 2003 at 11:35:22AM -0600, [EMAIL PROTECTED] wrote:
> The \timing psql command gives different time for the same query executed
> repeatedly.
Why do you believe that the same query will always take the same time
to execute?
A
--
Andrew Sullivan 204-41
<[EMAIL PROTECTED]> writes:
> The \timing psql command gives different time for the same query executed
> repeatedly.
That's probably because executing the query repeatedly results in
different execution times, as one would expect. \timing returns the
"exact" query response time, nevertheless.
-N
The \timing psql command gives different time for the same query executed
repeatedly.
So, how can we know the exact response time for any query?
Thanks and Regards,
Radha
> On Tue, 2003-11-04 at 09:49, [EMAIL PROTECTED] wrote:
>> How do we measure the response time in postgresql?
>
> In additio
On Tue, 2003-11-04 at 09:49, [EMAIL PROTECTED] wrote:
> How do we measure the response time in postgresql?
In addition to EXPLAIN ANALYZE, the log_min_duration_statement
configuration variable and the \timing psql command might also be
useful.
-Neil
---(end of broadcast
Hello
explain analyse select * from lidi;
QUERY PLAN
---
Seq Scan on lidi (cost=0.00..1.04 rows=4 width=96) (actual
time=0.046..0.092 rows=4 loops=1)
Total run
How do we measure the response time in postgresql?
Your response would be very much appreciated.
Thanks and Regards,
Radha
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
21 matches
Mail list logo
