From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Qi Huang <huangqiyx(at)hotmail(dot)com>, neil(dot)conway(at)gmail(dot)com, daniel(at)heroku(dot)com, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Gsoc2012 Idea --- Social Network database schema |
Date: | 2012-03-21 14:35:54 |
Message-ID: | 375.1332340554@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:
> One thing we should probably try to establish before you get started
> working on this is whether people want the feature, which is basically
> the ability to write something like this in the FROM clause of a
> query:
> table_name TABLESAMPLE { BERNOULLI | SYSTEM } ( sample_percent ) [
> REPEATABLE ( repeat_seed ) ] ]
> I have at present no position on whether we want that or not, but
> maybe someone else does. The upside is that would be a more efficient
> replacement for the ORDER BY random() trick that is often used today;
> the downside is that it requires dedicated syntax and a whole new
> executor node for something that, realistically, isn't going to come
> up very often.
Yeah --- you're talking about chunks of new code in both planner and
executor. A very rough estimate is that this might be about as
complicated to do properly as MergeAppend was (and we're still shaking
out the bugs in that :-().
Now that would all be fine if this were a widely-desired feature, but
AFAIR the user demand for it has been about nil. So I'm leaning to
the position that we don't want it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | lekon | 2012-03-21 14:39:39 | how can i see the log..? |
Previous Message | Tom Lane | 2012-03-21 14:22:41 | Re: Proposal: Create index on foreign table |