Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I looked at this but did not actually see the code path that requires
>> forcing creation of the per-DB entry right at this spot. The HASH_FIND
>> calls for this hashtable seem to all happen on the backend side not the
>> collector side. Can you explain why we need this?
> Yeah, I missed this when making the original change (this code is rather
> opaque :-\).
No kidding. Somebody ought to separate the collector-side code from the
backend-side code sometime.
> BTW, the comment at line 2210 of pgstat.c is misleading: the n_backends
> in the entries of the dbentry hash table are explicitly ignored when
> reading in the stats file -- the value is instead derived from the
> number of beentries that are seen.
Right. So do we care whether the collector has the right number?
Or should we push the responsibility for tracking that count over
to the collector (+1 for that personally)?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
