New relkind (was Re: Exposing quals)
От | David Fetter |
---|---|
Тема | New relkind (was Re: Exposing quals) |
Дата | |
Msg-id | 20080707232650.GI15394@fetter.org обсуждение исходный текст |
Ответ на | Re: Exposing quals (andrew@dunslane.net) |
Ответы |
Re: New relkind (was Re: Exposing quals)
|
Список | pgsql-hackers |
On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote: > > > > On Mon, 2008-05-05 at 12:01 -0700, David Fetter wrote: > > > >> Please find attached the patch, and thanks to Neil Conway and > >> Korry Douglas for the code, and to Jan Wieck for helping me > >> hammer out the scheme above. Mistakes are all mine ;) > > > > I see no negative comments to this patch on -hackers. > > > > This was discussed here > > http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting#SQL.2FMED > > and I had understood the consensus to be that we would go ahead > > with this? > > > > The notes say "Heikki doesn't think this is a long term solution", > > but in the following discussion it was the *only* way of doing > > this that will work with non-PostgreSQL databases. So it seems > > like the way we would want to go, yes? > > > > So, can we add this to the CommitFest July page so it can receive > > some substantial constructive/destructive comments? > > > > This could be an important feature in conjunction with Hot > > Standby. > > The notes say at the end: > > "Jan thinks that showing the node tree will work better. But others > don't agree with him -- it wouldn't work for PL/perlU. But Jan > thinks it would work to give it a pointer to the parse tree and the > range, we'd need to add an access function for the PL." > > For the record, I agree with Jan's suggestion of passing a pointer > to the parse tree, and offline gave David a suggestion verbally as > to how this could be handled for PL/PerlU. > > I don't think we should be tied too closely to a string > representation, although possibly the first and simplest callback > function would simply stringify the quals. As I understand Jan's plan, the idea is to create a new relkind with an exit to user code at leaf nodes in the plan tree. This would require an API design for both user C code and for each PL to use, but would then allow PostgreSQL's optimizer to work on JOINs, etc. Jan, have I got that right so far? Do you have something in the way of a rough patch, docs, etc. for this? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: