Re: sudden drop in statement turnaround latency -- yay!.
От | Tom Lane |
---|---|
Тема | Re: sudden drop in statement turnaround latency -- yay!. |
Дата | |
Msg-id | 11787.1104799734@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: sudden drop in statement turnaround latency -- yay!. ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Список | 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 по дате отправления: