| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | gsstark(at)mit(dot)edu, marcin(dot)mank(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: per table random-page-cost? |
| Date: | 2009-10-20 03:05:37 |
| Message-ID: | 1256007937.2580.30.camel@jdavis |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2009-10-19 at 21:22 -0500, Kevin Grittner wrote:
> I'd bet accounts receivable applications often hit that.
> (Most payments on recent billings; a sprinkling on older ones.)
> I'm sure there are others.
You worded the examples in terms of writes (I think), and we're talking
about read caching, so I still don't entirely understand.
Also, the example sounds like you'd like to optimize across queries.
There's no mechanism for the planner to remember some query executed a
while ago, and match it up to some new query that it's trying to plan.
Maybe there should be, but that's an entirely different feature.
I'm not clear on the scenario that we're trying to improve.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-10-20 04:08:32 | Re: Rejecting weak passwords |
| Previous Message | Kevin Grittner | 2009-10-20 02:22:02 | Re: per table random-page-cost? |