Re: About "Our CLUSTER implementation is pessimal" patch

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Leonardo F <m_lists(at)yahoo(dot)it>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: About "Our CLUSTER implementation is pessimal" patch
Date: 2010-01-22 14:19:47
Message-ID: 407d949e1001220619t58b43210tbc03c217a6d4f2e7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 21, 2010 at 4:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> You're poking into a data structure you shouldn't be poking into:
>
> /* Plans are opaque structs for standard users of SPI */
> typedef struct _SPI_plan *SPIPlanPtr;
>
> I hardly think that keeping yourself at arm's length from the planner
> by getting cozy with SPI internals is a net improvement in modularity.

You could do it without poking into the SPI structure. You could
define a planner_hook which calls the regular planner and then just
use SPI to drive the parser etc and invoke your planner hook. The
planner hook could inspect the plan, even modify it.

One of the plans I considered early on which I skipped on because I
thought it might get too complex was to add special syntax like
"SELECT __heaptuple__ from table ORDER BY ..." and then just run it
through the regular executor (and do some unspecified hackery around
the visibility rules).

Part of the reason I'm interested in using the regular planner as much
as possible is that if you have a partial index it could be a huge win
to use some unexpected different index to scan the part of the table
you need.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-01-22 14:22:57 Re: primary key error message
Previous Message Michael Meskes 2010-01-22 14:18:44 Re: Fix auto-prepare #2