Re: Expression Pruning in postgress

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: HarmeekSingh Bedi <harmeeksingh(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Expression Pruning in postgress
Date: 2011-07-10 17:28:37
Message-ID: 3562.1310318917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

HarmeekSingh Bedi <harmeeksingh(at)gmail(dot)com> writes:
> Thanks Tom. Here is a example. Just a background of things . I have made
> changes in postgress execution and storage engine to make it a MPP style
> engine - keeping all optimizer intact. Basically take pgress serial plan and
> construct a parallel plan. The query I am running is below.

The output lists for the parallel nodes look pretty broken, but I guess
you weren't asking about those. As near as I can tell, what you're
unhappy about is that it's passing up both raw column values and
pre-evaluated placeholder expressions using those values, when only the
placeholders are really going to be needed. Yeah, that's probably true,
because the placeholder mechanism isn't (yet) taken into account by the
code that determines how far up a column value will be needed.

In standard Postgres this isn't much of an issue because passing up
by-reference Datums is really quite cheap ... it's only a pointer copy
in many cases, and even where it's not, it's probably just a
toast-pointer copy. I suspect it's costing you more because your
"parallel" nodes have to instantiate the tuples instead of just passing
virtual slots around ... but it's still not clear to me why you're
passing more than a toast pointer for big values. Maybe you're being
too enthusiastic about detoasting pointers early?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-07-10 18:09:04 Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Previous Message Tom Lane 2011-07-10 16:51:15 Re: Enhanced psql in core?