| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
| Cc: | "pgsqlperform" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: sudden drop in statement turnaround latency -- yay!. |
| Date: | 2005-01-04 00:48:54 |
| Message-ID: | 11787.1104799734@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2005-01-04 00:57:20 | Re: Low Performance for big hospital server .. |
| Previous Message | Stan Y | 2005-01-04 00:13:45 | PostgreSQL's Statspack? |