On 12/5/11 1:36 PM, Kevin Grittner wrote:
> I understand the impulse to run autovacuum less frequently or less
> aggressively. When we first started running PostgreSQL the default
> configuration was very cautious.
The default settings are deliberately cautious, as default settings
should be.
Bu
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
On 12/06/2011 09:29 PM, Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>
>> But both servers develop that estimate for the join size.
>
> [sigh] Those *were* both from the production server. Please show
> us the EXPLAIN ANALYZE from the other server.
Huh, right... missed that one. Here is
On 12/06/2011 09:17 PM, Kevin Grittner wrote:
>
> The hash join path must look more expensive on the first machine,
> for some reason.
>
> Mario, could you post the result of running this query from both
> servers?:
>
> http://wiki.postgresql.org/wiki/Server_Configuration
Sure. Here is from
On 12/06/2011 09:00 PM, Tom Lane wrote:
> Mario Splivalo writes:
>> I have 8.4.8 on producion and 8.4.9 on test, could that explain the
>> difference in plans chosen?
>
> I'd wonder first if you have the same statistics settings on both.
> The big problem here is that the estimation of the join s
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
"Kevin Grittner" wrote:
> But both servers develop that estimate for the join size.
[sigh] Those *were* both from the production server. Please show
us the EXPLAIN ANALYZE from the other server.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
Tom Lane wrote:
> I'd wonder first if you have the same statistics settings on both.
> The big problem here is that the estimation of the join size is
> bad (8588 versus 0).
But both servers develop that estimate for the join size. I was
wondering more about whether the costing factors were r
Mario Splivalo writes:
> I have 8.4.8 on producion and 8.4.9 on test, could that explain the
> difference in plans chosen?
I'd wonder first if you have the same statistics settings on both.
The big problem here is that the estimation of the join size is bad
(8588 versus 0).
I have a fairly simple query:
SELECT
FROM "tubesite_image"
INNER JOIN "tubesite_object"
ON ("tubesite_image"."object_ptr_id" = "tubesite_object"."id")
WHERE
"tubesite_object"."site_id" = 8
ORDER BY
"tubesite_object"."pub_date" ASC LIMIT 21;
That query is having a bad qu
10 matches
Mail list logo
