Re: Gsoc2012 idea, tablesample

From: Greg Stark <stark(at)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, josh(at)agliodbs(dot)com, andres(at)anarazel(dot)de, alvherre(at)commandprompt(dot)com, ants(at)cybertec(dot)at, heikki(dot)linnakangas(at)enterprisedb(dot)com, cbbrowne(at)gmail(dot)com, neil(dot)conway(at)gmail(dot)com, daniel(at)heroku(dot)com, huangqiyx(at)hotmail(dot)com, Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org, sfrost(at)snowman(dot)net, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Gsoc2012 idea, tablesample
Date: 2012-05-11 17:52:46
Message-ID: CAM-w4HO_+XoqF8cYwNAibDtwWCNL1zBOCWFr_XJ4gnEbDw526A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 11, 2012 at 6:16 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> MaxHeapTuplesPerPage?
>
> What about dead line pointers without corresponding tuples?

Actually we don't allow there to be more than MaxHeapTuplesPerPage
line pointers even if some of them are dead line pointers.

I think the argument then was that there could be bugs in code that
isn't expecting more so perhaps that doesn't justify baking that into
more places when we could instead be removing that assumption.

Also, if I absorbed enough of this conversation skimming backwards it
seems the algorithm would be very inefficient with such a conservative
estimate. On a table with normal width rows it would mean usually
picking tuples that don't exist and having to try again. As Tom
pointed out that would mean even a small sample would have to read
nearly the whole table to find the sample.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-05-11 18:01:17 Re: WalSndWakeup() and synchronous_commit=off
Previous Message Robert Haas 2012-05-11 17:45:35 Re: Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value