2015-02-22 13:22 GMT+01:00 Andres Freund :
> On 2015-02-22 10:33:16 +, Andrew Gierth wrote:
> > 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
On 2015-02-22 09:58:31 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I've wondered before if we shouldn't use the caching via
> > slot->tts_values so freely - if you only use a couple values from a wide
> > tuple the current implementation really sucks if those few aren't at the
> > beginning
Andres Freund writes:
> I've wondered before if we shouldn't use the caching via
> slot->tts_values so freely - if you only use a couple values from a wide
> tuple the current implementation really sucks if those few aren't at the
> beginning of the tuple.
Don't see how you expect to get a win th
On 2015-02-22 10:33:16 +, Andrew Gierth wrote:
> 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 ne
> "Pavel" == Pavel Stehule 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 fas
2015-02-22 9:28 GMT+01:00 Pavel Stehule :
> Hi
>
> I did some benchmarks and I found some strange numbers.
>
> do $$
> begin
> drop table if exists t1;
> execute 'create table t1(' ||
> array_to_string(array(select 'a' || i || ' smallint' from
> generate_series(1,30) g(i)), ',') || ')';
>
Hi
I did some benchmarks and I found some strange numbers.
do $$
begin
drop table if exists t1;
execute 'create table t1(' ||
array_to_string(array(select 'a' || i || ' smallint' from
generate_series(1,30) g(i)), ',') || ')';
-- special column a2, a11
insert into t1
select 2008,
