>>>>> "Pavel" == Pavel Stehule <pavel.steh...@gmail.com> writes:
Pavel> why we read all columns from t1? [...] Pavel> so it looks so hashagg doesn't eliminate source columns well I don't think it's supposed to eliminate them. This is, if I'm understanding the planner logic right, physical-tlist optimization; it's faster for a table scan to simply return the whole row (copying nothing, just pointing to the on-disk tuple) and let hashagg pick out the columns it needs, rather than for the scan to run a projection step just to select specific columns. If there's a Sort step, this isn't done because Sort neither evaluates its input nor projects new tuples on its output, it simply accepts the tuples it receives and returns them with the same structure. So now it's important to have the node providing input to the Sort projecting out only the minimum required set of columns. Why it's slower on the wider table... that's less obvious. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
