From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Hoffmann <jeff(at)propertykey(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: question about index cost estimates |
Date: | 2000-05-18 05:02:28 |
Message-ID: | 21989.958626148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Hoffmann <jeff(at)propertykey(dot)com> writes:
> it seems in the big picture, we're subject to the whims of the disk
> cache more than anything.
Ain't that the truth. Maybe we ought to think about whether there's any
way to find out how big the kernel's disk cache is. Even if it only
worked on some platforms, we'd be no worse off on the other ones...
> I'm assuming you're considering adding some sort of histogram to the
> stats that vacuum collects. is that something that you're seriously
> considering or do you have another plan to introduce a useful concept
> of the distribution of an attribute? the concept of making a
> histogram on a b-tree is pretty simple, but if you're going to do it,
> you should probably be taking into account r-trees, where you'd need a
> 2-d histogram making the job just a bit tougher.
I was considering a histogram for b-trees, but I have to admit I hadn't
thought about r-trees. Seems like a 2-D histogram would be too bulky
to be feasible. Could we get any mileage out of two 1-D histograms
(ie, examine the two coordinates independently)? Or is that too
simplistic to be worth bothering with?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-18 05:14:10 | Re: question about index cost estimates |
Previous Message | Jeff Hoffmann | 2000-05-18 04:49:23 | Re: question about index cost estimates |