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
]
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.
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
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
[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
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
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
> >
> > 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
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
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, (
> 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
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
12 matches
Mail list logo
