Re: [PERFORM] How to read query plan

From: Miroslav Šulc <miroslav(dot)sulc(at)startnet(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PERFORM] How to read query plan
Date: 2005-03-14 08:44:48
Message-ID: 42354F00.5060904@startnet.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Tom Lane wrote:

>I wrote:
>
>
>>Since ExecProject operations within a nest of joins are going to be
>>dealing entirely with Vars, I wonder if we couldn't speed matters up
>>by having a short-circuit case for a projection that is only Vars.
>>Essentially it would be a lot like execJunk.c, except able to cope
>>with two input tuples. Using heap_deformtuple instead of retail
>>extraction of fields would eliminate the O(N^2) penalty for wide tuples.
>>
>>
>
>Actually, we already had a pending patch (from Atsushi Ogawa) that
>eliminates that particular O(N^2) behavior in another way. After
>applying it, I get about a factor-of-4 reduction in the runtime for
>Miroslav's example.
>
>
Is there a chance we will see this patch in the 8.0.2 release? And when
can we expect this release?

>ExecEvalVar and associated routines are still a pretty good fraction of
>the runtime, so it might still be worth doing something like the above,
>but it'd probably be just a marginal win instead of a big win.
>
> regards, tom lane
>
>
Miroslav

Attachment Content-Type Size
miroslav.sulc.vcf text/x-vcard 387 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Miroslav Šulc 2005-03-14 08:58:49 Re: How to read query plan
Previous Message Miroslav Šulc 2005-03-14 08:43:19 Re: [PERFORM] How to read query plan

Browse pgsql-performance by date

  From Date Subject
Next Message Gourish Singbal 2005-03-14 08:48:55 Re: column name is "LIMIT"
Previous Message Miroslav Šulc 2005-03-14 08:43:19 Re: [PERFORM] How to read query plan