Re: sudden drop in statement turnaround latency -- yay!. - Mailing list pgsql-performance

From Tom Lane
Subject Re: sudden drop in statement turnaround latency -- yay!.
Date
Msg-id 11787.1104799734@sss.pgh.pa.us
Whole thread Raw
In response to Re: sudden drop in statement turnaround latency -- yay!.  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-performance
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> Tom Lane wrote:
>> Add a small cost factor to ensure we
>> prefer materializing the smaller input.  This changes several
>> regression test plans, but with any luck we will now have more
>> stability across platforms.

> No.  The planner is not a factor.

You are missing the point: the possible change in a generated plan could
be a factor.

>> Change planner to use
>> the current true disk file size as its estimate of a relation's
>> number of blocks, rather than the possibly-obsolete value in
>> pg_class.relpages.

> doesn't seem like this would apply.

Same point.  Unless you have done EXPLAINs to verify that the same plans
were used before and after, you can't dismiss this.

>> * src/backend/utils/cache/relcache.c: Avoid scanning the
>> relcache
>> during AtEOSubXact_RelationCache when there is nothing to do,
>> which
>> is most of the time.  This is another simple improvement to cut
>> subtransaction entry/exit overhead.

> Not clear from the comments: does this apply to every transaction, or
> only ones with savepoints?  If all transactions, it's a contender.

It only applies to subtransactions, ie something involving savepoints.

            regards, tom lane

pgsql-performance by date:

Previous
From: Stan Y
Date:
Subject: PostgreSQL's Statspack?
Next
From: Dave Cramer
Date:
Subject: Re: Low Performance for big hospital server ..