On Sat, Nov 14, 2009 at 6:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm not really convinced of that, but even if we do, so what? It's not
> that much code to have an extra cache watching the syscache traffic.
> There's an example in parse_oper.c of a specialized cache that's about
> as complicated as this would be. It's about 150 lines including copious
> comments. We didn't even bother to split it out into its own source
> file.
Well, if it's that simple maybe it's not too bad. I'll take a look at that one.
>> With
>> hardwired columns, a regular catcache is all we need. But the
>> reloptions stuff is designed to populate a struct, and once we
>> populate that struct we have to have someplace to hang it - or I guess
>> maybe we could reparse it on every call to cost_seqscan(),
>> cost_index(), genericcostestimate(), etc, but that doesn't seem like a
>> great idea.
>
> Well, no, we would not do it that way. I would imagine instead that
> plancat.c would be responsible for attaching appropriate cost values to
> each RelOptInfo struct, so it'd be more like one lookup per referenced
> table per query. It's possible that a cache would be useful even at
> that load level, but I'm not convinced.
I'm not sure exactly what you mean by the last sentence, but my
current design attaches the tablespace OID to RelOptInfo (for baserels
only, of course) and IndexOptInfo, and the costing functions trigger
the actual lookup of the page costs. I guess that might be slightly
inferior to actually attaching the actualized values to the
RelOptInfo, since each possible index-path needs the values for both
the index and the underlying table.
I will take another crack at it.
...Robert
