Hi
Which scheduler is recommended for a box that is dedicated to running
postgres?
I've asked google and found no answers.
--
Adrian Moisey
System Administrator | CareerJunction | Your Future Starts Here.
Web: www.careerjunction.co.za | Email: [EMAIL PROTECTED]
Phone: +27 21 686 6820 | Mobile
Em Mon, 21 Jan 2008 15:45:54 -0800
Jeff Davis <[EMAIL PROTECTED]> escreveu:
> On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote:
> > pgbench doesn't handle 100 clients at once very well on the same
> > box as the server, unless you have a pretty serious system. The
> > pgbench program itself ha
On Mon, 21 Jan 2008, Jeff Davis wrote:
He was referring to the CFQ I/O scheduler. I don't think that will
affect pgbench itself, because it doesn't read/write to disk, right?
It does if you are writing latency log files but it shouldn't be in the
cases given. But there's something weird abou
On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote:
> pgbench doesn't handle 100 clients at once very well on the same box as
> the server, unless you have a pretty serious system. The pgbench program
> itself has a single process model that doesn't handle the CFQ round-robin
> very well at al
On Mon, 21 Jan 2008, Hannes Dorbath wrote:
pgbench -i -s 10 -U pgsql -d bench && pgbench -t 1000 -c 100 -U pgsql -d
bench
pgbench doesn't handle 100 clients at once very well on the same box as
the server, unless you have a pretty serious system. The pgbench program
itself has a single proc
On Mon, 2008-01-21 at 22:55 +0100, Hannes Dorbath wrote:
> I might completely misunderstand this feature. Shouldn't
> "synchronous_commit = off" improve performance?
>
> Whatever I do, I find "synchronous_commit = off" to degrade performance.
>
> Especially it doesn't like the CFQ I/O scheduler
Hello
synchronous_commit = off is well for specific load,
try only one connect pgbench ~ it is analogy for database import or
some administrator's work.
Regards
Pavel Stehule
On 21/01/2008, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
> I might completely misunderstand this feature. Shouldn't
> "
I might completely misunderstand this feature. Shouldn't
"synchronous_commit = off" improve performance?
Whatever I do, I find "synchronous_commit = off" to degrade performance.
Especially it doesn't like the CFQ I/O scheduler, it's not so bad with
deadline. Synthetic load like
pgbench -i -
On Jan 21, 2008, at 1:58 AM, Adrian Moisey wrote:
Perhaps, if you want to avoid I/O caused by temp tables (but it's
not at
checkpoint time, so perhaps this has nothing to do with your
problem),
you could try raising temp_buffers.
How can I find out if temp_buffers is being exceeded ?
You
Hello
> > Filter: ((COALESCE((at_type)::integer, 1) = 1) AND
> > (COALESCE(at_language, 0::numeric) = 0::numeric))
>
> If this is slow, it must be that the scan of fpuarticletext actually
> returns many more rows than the single row the planner is expecting.
> The reason the estimat
"Marten Verhoeven" <[EMAIL PROTECTED]> writes:
> This is the query analysis:
> Nested Loop Left Join (cost=1796.69..3327.98 rows=5587 width=516)
> Join Filter: (fpuarticle.a_no = fpuarticletext.at_a_no)
> Filter: (strpos(lowerCOALESCE(fpuarticle.a_code, ''::character
> varying))::text |
Hello
please, send output EXPLAIN ANALYZE statement
Regards
Pavel Stehule
On 21/01/2008, Marten Verhoeven <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> Since I moved from PostgreSQL 7.3 to 8.2 I have a query which suddenly runs
> very slow. In 7.3 it was really fast. It seems that the query analyser
Hi,
Since I moved from PostgreSQL 7.3 to 8.2 I have a query which suddenly runs
very slow. In 7.3 it was really fast. It seems that the query analyser makes
other choices, which I don't understand.
I have the query:
SELECT * FROM fpuArticle
LEFT OUTER JOIN fpuArticleText ON a_No=at_a_N
Hi
Perhaps, if you want to avoid I/O caused by temp tables (but it's not at
checkpoint time, so perhaps this has nothing to do with your problem),
you could try raising temp_buffers.
How can I find out if temp_buffers is being exceeded ?
--
Adrian Moisey
System Administrator | CareerJunction
14 matches
Mail list logo