From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Our CLUSTER implementation is pessimal |
Date: | 2008-09-08 12:47:46 |
Message-ID: | 12948.1220878066@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Yeah, I've been thinking about how to use the planner to do this.
I thought the answer to that was going to be more or less "call
cost_sort() and cost_index() and compare the answers".
> To do that it seems to me what we would need to do is add a function
> _pg_get_rawtuple_header() which returns the visibility information that HTSV
> needs.
You seem to be confusing "use the planner" with "use the executor".
All that we need here is a decision about which code path to take
within CLUSTER. We don't need to bring in boatloads of irrelevant
infrastructure --- especially not infrastructure that's going to be
fighting us every step of the way. The executor isn't designed to
return raw tuples and no magic function is going to change that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-09-08 12:54:48 | Re: [PATCH] Cleanup of GUC units code |
Previous Message | Tom Lane | 2008-09-08 12:39:29 | Re: [PATCH] Cleanup of GUC units code |