| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Qi Huang <huangqiyx(at)hotmail(dot)com>, "neil(dot)conway" <neil(dot)conway(at)gmail(dot)com>, daniel <daniel(at)heroku(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Gsoc2012 Idea --- Social Network database schema |
| Date: | 2012-03-21 16:00:40 |
| Message-ID: | 2016.1332345640@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Well, there's something mighty tempting about having a way to say
> "just give me a random sample of the blocks and I'll worry about
> whether that represents a random sample of the rows".
> It's occurred to me a few times that it's pretty unfortunate you can't
> do that with a TID condition.
> rhaas=# explain select * from randomtext where ctid >= '(500,1)' and
> ctid < '(501,1)';
Yeah, as you say that's come up more than once in data-recovery
situations. It seems like it'd be just a SMOP to extend the tidscan
stuff to handle ranges.
Another thing that people sometimes wish for is joins using TIDs.
I think the latter would actually be pretty trivial to do now given the
parameterized-plan infrastructure; I'd hoped to look into it for 9.2 but
ran out of time...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-03-21 16:15:17 | Re: Weak-memory specific problem in ResetLatch/WaitLatch (follow-up analysis) |
| Previous Message | Andrew Dunstan | 2012-03-21 15:59:49 | Re: Gsoc2012 Idea --- Social Network database schema |