Re: O(samplesize) tuple sampling, proof of concept

On Mon, 05 Apr 2004 18:30:29 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> noise-contributing factors.
>
>I think it would have to be visibility-bit updates. Can you try it with
>a pre-vacuumed relation, so that there is no slowdown for updates?

I'd like to avoid VACUUM to keep the dead tuples. Otherwise we'd have
nothing to judge the quality of the row count estimation. SELECT
count(*) ... should do as well. And I'll also issue a CHECKPOINT to
make sure that the following ANALYSE doesn't have to write out dirty
pages.

>Yeah, so I managed to read it anyway ;-). It's the ones with
>intricately intermixed "-" and "+" that I find difficult to follow.

<ot>
Vim nicely marks "+" and "-" lines in different colours. That makes you
read -u diffs almost like a newspaper, your eyes automatically ignore
lines that have the wrong colour. I can't get myself used to reading -c
diffs. Jumping up and down to find corresponding lines makes me
nervous. Anyway, just a matter of taste ...
</ot>

>Duh, you're right --- I was thinking that the old code doesn't need a
>qsort, but it does. This seems a tad annoying considering that we know
>the tuples were inserted into the pool in increasing order. I wonder if
>it's worth using a more complex data structure to keep track of both
>orders at once? I suppose that could easily wind up costing more than
>the qsort though ...

The least complex structure I can think of is a doubly linked list
combined with an array. This can be done later, if we find it's worth
it (which I doubt).

Servus
Manfred