Comments on: PostgreSQL adds windowing functions and common table expressions http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/ Stay curious! Thu, 09 Feb 2012 20:41:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Mark http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/#comment-18061 Mark Wed, 24 Mar 2010 13:49:20 +0000 http://www.xaprb.com/blog/?p=782#comment-18061 I'm starting to see the light with Postgresql myself. There are two major knocks to mysql in developing my application. 1) It doesn't support recursive queries, which allows me to avoid cursors without thinking too hard. 2) It doesn't support dbi link-like functionality where I can query another database from a different vendor without using an ETL tool. 3) It's not quite ANSI-SQL IMHO. MySql comes in front in terms of error handling now that they've added signal. And also they can natively support clusters via their NDB engine. (Which I have yet to fool around with but I don't hear much about it). Performance I haven't had enough exposure to comment on. I’m starting to see the light with Postgresql myself. There are two major knocks to mysql in developing my application. 1) It doesn’t support recursive queries, which allows me to avoid cursors without thinking too hard. 2) It doesn’t support dbi link-like functionality where I can query another database from a different vendor without using an ETL tool. 3) It’s not quite ANSI-SQL IMHO. MySql comes in front in terms of error handling now that they’ve added signal. And also they can natively support clusters via their NDB engine. (Which I have yet to fool around with but I don’t hear much about it). Performance I haven’t had enough exposure to comment on.

]]> By: VLDG http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/#comment-16354 VLDG Wed, 29 Apr 2009 22:08:31 +0000 http://www.xaprb.com/blog/?p=782#comment-16354 CTE's is great : I discover this in Firebird 2.1 and it's great SQL enhancement :) CTE’s is great : I discover this in Firebird 2.1 and it’s great SQL enhancement :)

]]> By: Xaprb http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/#comment-15731 Xaprb Fri, 23 Jan 2009 19:14:12 +0000 http://www.xaprb.com/blog/?p=782#comment-15731 "Can you elaborate on why left-deep nested-loops query plans makes it easier?" Hey, I had a disclaimer there! I love disclaimers. I wasn't being precise with my language. What I mean is something more like the following: A storage engine API in general isn't to blame, but MySQL's has caused a gripe or two from storage engine writers whose engines have extra intelligence that ought to live at a lower level than the server layer in MySQL. And I'm being cavalier in my original text, and conflating that with the difficulty the nested-loop plan causes for more intricate queries. Let me shift the blame and go completely off-topic to distract readers from my carelessness: The nested-loop query plan may be part of the reason MySQL doesn't currently support FULL OUTER JOIN. FULL OUTER JOIN is perfectly possible with the storage engine API. The server does IN() subqueries with the storage engine API in a suboptimal way. Feel the cognitive dissonance! Just try forming a coherent argument against that! “Can you elaborate on why left-deep nested-loops query plans makes it easier?”

Hey, I had a disclaimer there! I love disclaimers.

I wasn’t being precise with my language. What I mean is something more like the following: A storage engine API in general isn’t to blame, but MySQL’s has caused a gripe or two from storage engine writers whose engines have extra intelligence that ought to live at a lower level than the server layer in MySQL. And I’m being cavalier in my original text, and conflating that with the difficulty the nested-loop plan causes for more intricate queries. Let me shift the blame and go completely off-topic to distract readers from my carelessness:

The nested-loop query plan may be part of the reason MySQL doesn’t currently support FULL OUTER JOIN. FULL OUTER JOIN is perfectly possible with the storage engine API. The server does IN() subqueries with the storage engine API in a suboptimal way.

Feel the cognitive dissonance! Just try forming a coherent argument against that!

]]> By: Shlomi Noach http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/#comment-15725 Shlomi Noach Thu, 22 Jan 2009 11:21:09 +0000 http://www.xaprb.com/blog/?p=782#comment-15725 @Lukas, Of course, you are right. I was referring to the SQL implementation part. Still other issues are with locking (how do you coordinate locks between different engines?), transactions (rolling back and synchronous commit for two different transactional engines), backup types and more. @Lukas,

Of course, you are right. I was referring to the SQL implementation part. Still other issues are with locking (how do you coordinate locks between different engines?), transactions (rolling back and synchronous commit for two different transactional engines), backup types and more.

]]> By: Andy http://www.xaprb.com/blog/2009/01/21/postgresql-adds-windowing-functions-and-common-table-expressions/#comment-15723 Andy Thu, 22 Jan 2009 08:21:58 +0000 http://www.xaprb.com/blog/?p=782#comment-15723 depesz.com has a good post on CTE's in PG 8.4 as well: <a href="http://www.depesz.com/index.php/2008/10/07/waiting-for-84-common-table-expressions-with-queries/" rel="nofollow">http://www.depesz.com/index.php/2008/10/07/waiting-for-84-common-table-expressions-with-queries/</a> And the Postgres documentation: <a href="http://developer.postgresql.org/pgdocs/postgres/queries-with.html" rel="nofollow">http://developer.postgresql.org/pgdocs/postgres/queries-with.html</a> depesz.com has a good post on CTE’s in PG 8.4 as well:
http://www.depesz.com/index.php/2008/10/07/waiting-for-84-common-table-expressions-with-queries/

And the Postgres documentation:
http://developer.postgresql.org/pgdocs/postgres/queries-with.html

]]>