Consider a table and a query referring to only a subset of the columns
in that table. How early in the query evaluation is the projection
carried out?
Are the columns to be selected filtered out as early as in the very
access method that reads the table rows from the buffer, or are the
Thanks for the clarification!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
You could add it to here -- note that if we decide it isn't worth it it'll
just get removed.
Which category would you recommend? Optimizer / Executor?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
I would tend to think it's worth it myself.
I am unfortunately not familiar enough with the postgresql code base to
be comfortable to provide a patch. Can I submit this optimization
request to some sort of issue tracker or what should I do?
--
Sent via pgsql-hackers mailing list
As far as I have understood the following query
SELECT DISTINCT foo
FROM bar
LIMIT baz
is done by first sorting the input and then traversing the sorted data,
ensuring uniqueness of output and stopping when the LIMIT threshold is
reached. Furthermore, a part of the sort procedure is to
In principle, if there are no aggregate functions, then nodeAgg could
return a row immediately upon making any new entry into the hash table.
Whether it's worth the code uglification is debatable ... I think it
would require a third major pathway through nodeAgg.
Regarding whether it's worth
