Re: Access statistics - Mailing list pgsql-patches

Tom Lane wrote:
> Jan Wieck <JanWieck@yahoo.com> writes:
> >> You can't count heapscan info via the relcache entry --- what if there's
> >> more than one heapscan in progress on the same rel?  What if the
> >> relcache entry gets rebuilt by SI invalidation?  I don't think the stats
> >> stuff should touch the relcache at all.
>
> >     The  counting end's up in one and the same global slot of the
> >     tabstat messages. These  slots  are  collected  per  frontend
> >     command  and are identified by the tables oid. Does it matter
> >     how often the pointer to that slot is  updated  to  the  same
> >     value?
>
> In that case, forget about the fields in the heapscan and indexscan
> structs.  You can easily keep both the heap and index access counts
> in (or referenced by) the relcache entry, no?  It just bothers me
> that the treatment of heap and index counts is so inconsistent.
> One or the other is wrong, or at least inefficient.

    heap  tuples  fetched  due  to  an  index scan are counted as
    tuples_fetched on the indexes entry. Only heap_fetch()  calls
    not  done  due to an index scan count into the tuples_fetched
    count for the  table  (e.g.  tuples  refetched  for  deferred
    trigger invocation and the like).

>
> BTW, does it really matter whether we are counting an index-driven
> or heap-driven fetch?  Seems to me that if you count indextuple and
> heaptuple fetches, you can figure out what's going on without having
> to have heap_fetch know the difference.
>
> >> Also, I do not like the pgStatPmPipe mechanism for detecting postmaster
> >> shutdown.  That eats two file descriptors in every backend, which is a
> >> pretty substantial waste of resources.  Why not just have the postmaster
> >> send a signal to the stats collector when it's time to shut down?
>
> >     Don't kill -9 the postmaster :-)
>
> What's your point?  If the postmaster crashes, whether the stats
> collector goes away without help seems like the least of your worries.
> You'll end up killing backends manually anyhow, so why not the stats
> process too?  (For that matter, do you care if the stats process doesn't
> die?  Once there is no one left to send messages to it, it'll never do
> anything, no?)

    Except  for  generating  another FAQ. We haven't been able to
    stop ppl from killing the postmaster up to now.  Why  do  you
    think they'll ever learn? They are human ...


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com