iowait is a problem on any platform that relies on spinning media, compared
to RAM.
no matter how fast a disk is, and no matter how intelligent the controller
is, you are still dealing with an access speed differential of 10^6 (speed
of disk access compared to memory access).
i have had good result
> It would be easier to suggest what might be wrong if you included "EXPLAIN
> ANALYZE" output instead of just EXPLAIN.
> It's not obvious whether 8.3 or 8.4 is estimating things better.
Thanks for reply man
Turns out random_page_cost was set low in the 8.3.10 version - when I reset it
to 4(dfl
I found the difference.
Random_page_cost is 1 in the production 8.3.10, I guess weighting the decision
to use "index scan".
Thanks for the replies, gentlemen.
> If you diff the postgresql.conf files for both installs, what's different?
In the list below, 8.3.10 parameter value is in the clear, (
Hi
My question is: Was there any major optimizer change between 8.3.10 to
8.3.14?
I'm getting a difference in explain plans that I need to account for.
We are running production pg8.3.10, and are considering upgrading to 8.4.x
(maybe 9.0), because we expected to benefit from some of th
> >
> > What is the procedure that postgres uses to decide whether or not a
> > table/index block will be left in the shared_buffers cache at the end
> > of the operation?
> >
>
> The only special cases are for sequential scans and VACUUM, which use
> continuously re-use a small section of the b
Question regarding the operation of the shared_buffers cache and implications
of the pg_X_stat_tables|pg_X_stat_indexes stats.
( I am also aware that this is all complicated by the kernel cache behavior,
however, if, for the purpose of these questions, you wouldn't mind assuming
that we don't ha
Hey
Turned on log_min_duration_statement today and started getting timings on sql
statements (version 8.3.10).
Can anyone please tell me how to interpret the (S_nn/C_nn) information in the
log line.
LOG: duration: 19817.211 ms execute S_73/C_74: (statement text) .
Thanks for your tim
[mailto:aburn...@bzzagent.com]
Sent: Monday, August 16, 2010 7:20 PM
To: Mark Rostron; pgsql-performance@postgresql.org
Subject: RE: Very poor performance
Thanks Mark,
Yeah, I apologize, I forgot to mention a couple of things.
m.id is the primary key but the biggest problem is that the query loops 626410
This is weird - is there a particular combination of memberid/answered in
answerselectindex that has a very high rowcount?
First change I would suggest looking into would be to try changing sub-query
logic to check existence and limit the result set of the sub-query to a single
row
Select dist
We are running 8.3.10 64bit.
Compare the plans below.
They all do the same thing and delete from a table named work_active (about
500rows), which is a subset of work_unit (about 50m rows).
I want to introduce range-partitions on work_unit.id column (serial pk), and I
want constraint exclusio
]
Sent: Sunday, August 01, 2010 7:08 AM
To: Mark Rostron
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] what does "initplan" operation in explain output mean?
Mark Rostron writes:
> This message is a request for information about the "initplan" operation
We are running 8.3.10 64bit.
This message is a request for information about the "initplan" operation in
explain plan.
I want to know if I can take advantage of it, and use it to initialize
query-bounds for the purpose of enforcing constraint exclusion on a table which
has been range-partition
12 matches
Mail list logo
