Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Are there more details about this? As a regular CTE use is both Postgres and MSSQL, but was unaware of this difference, I would like to know where I may be shooting performance to hell.


From the docs (http://www.postgresql.org/docs/9.2/static/queries-with.html):

> A useful property of WITH queries is that they are evaluated only once per execution of the parent query, even if they are referred to more than once by the parent query or sibling WITH queries. Thus, expensive calculations that are needed in multiple places can be placed within a WITH query to avoid redundant work. Another possible application is to prevent unwanted multiple evaluations of functions with side-effects. However, the other side of this coin is that the optimizer is less able to push restrictions from the parent query down into a WITH query than an ordinary sub-query. The WITH query will generally be evaluated as written, without suppression of rows that the parent query might discard afterwards. (But, as mentioned above, evaluation might stop early if the reference(s) to the query demand only a limited number of rows.)

In other words, something like:

    with x as (select * from users) select * from x limit 1
will be executed identically to

    select * from users limit 1
However, a query like this:

    with x as (
      select * from users
      join images on images.id = users.image_id
    )
    select * from x limit 1
will incur a huge overhead compared to:

    select * from users
    join images on images.id = users.image_id
    limit 1
In my test, the "WITH" query had a cost of 97840 and touched 8881 buffers, compared to a cost of 132 and 41 buffers for the second query.

In other words, the planner pretty much considers the "WITH" subquery separately from the outer query, and plans them separately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: