From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: RFC: planner statistics in 7.2 |
Date: | 2001-04-23 18:15:02 |
Message-ID: | 200104231815.NAA02885@jupiter.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> > A different approach that's been discussed on pghackers is to make use
> > of btree indexes for columns that have such indexes: we could scan the
> > indexes to visit all the column values in sorted order. I have rejected
> > that approach because (a) it doesn't help for columns without a suitable
> > index; (b) our indexes don't distinguish deleted and live tuples,
> > which would skew the statistics --- in particular, we couldn't tell a
> > frequently-updated single tuple from a commonly repeated value; (c)
> > scanning multiple indexes would likely require more total I/O than just
> > grabbing sample tuples from the main table --- especially if we have to
> > do that anyway to handle columns without indexes.
>
> Remember one idea is for index scans to automatically update the expired
> flag in the index bitfields when they check the heap tuple.
And we should really do that. While playing around with my
(for 7.2 to be) access statistics stuff I found that when
running pg_bench, a couple of thousand index scans cause
millions and millions of buffer fetches, because that
pg_bench updates one and the same row over and over again and
it has a PKEY.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-04-23 19:11:05 | Re: refusing connections based on load ... |
Previous Message | The Hermit Hacker | 2001-04-23 18:09:53 | refusing connections based on load ... |