Re: New relkind (was Re: [HACKERS] Exposing quals)
Simon Riggs wrote: On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote: On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote: 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? It sounds like we can make it happen as text for other DBMS and as plan nodes for PostgreSQL, which is the best solution all round. Personally not too worried which way we do this - as long as we do it for 8.4 :-) It's obviously happening in the background, so I'll leave it alone. I think the concept involving the plan tree is gold. Hannu Krosing mentioned some idea like that recently as well. If the function had the chance to tell the planner how it is gonna operate (e.g produces sorted output, etc.) it would be perfect. The golden thing here would be if we could teach a function whether it is STREAMABLE | NOT STREAMABLE. streamable would make sure that we don't have to materialize the output of a set returning function. this would allow google-like analysis in postgresql easily by allowing to fetch data from any amount of data from any data source. best regards, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, A-2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
New relkind (was Re: [HACKERS] Exposing quals)
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 [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: New relkind (was Re: [HACKERS] Exposing quals)
On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote: On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote: 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? It sounds like we can make it happen as text for other DBMS and as plan nodes for PostgreSQL, which is the best solution all round. Personally not too worried which way we do this - as long as we do it for 8.4 :-) It's obviously happening in the background, so I'll leave it alone. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
