Re: [HACKERS] [PERFORM] How to read query plan

2005-03-20 Thread Miroslav Šulc
Tom Lane wrote: ... I think the reason this is popping to the top of the runtime is that the joins are so wide (an average of ~85 columns in a join tuple according to the numbers above). Because there are lots of variable-width columns involved, most of the time the fast path for field access does

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-20 Thread John Arbash Meinel
Miroslav Šulc wrote: Tom Lane wrote: ... I think the reason this is popping to the top of the runtime is that the joins are so wide (an average of ~85 columns in a join tuple according to the numbers above). Because there are lots of variable-width columns involved, most of the time the fast path

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-20 Thread Miroslav Šulc
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

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-20 Thread Miroslav Šulc
Tom Lane wrote: =?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes: As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't be helpful to change them to char(1)? Would it solve the variable-width problem at least for some fields and speed the query up? No, becaus

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-14 Thread Tom Lane
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> 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 >> Miros

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-14 Thread Tom Lane
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes: > As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't > be helpful to change them to char(1)? Would it solve the variable-width > problem at least for some fields and speed the query up? No, because char(1) isn't p

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-13 Thread Tom Lane
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

Re: [HACKERS] [PERFORM] How to read query plan

2005-03-13 Thread Tom Lane
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes: >> Is the data confidential? If you'd be willing to send me a pg_dump >> off-list, I'd like to replicate this test and try to see where the time >> is going. >> > Thank you very much for your offer. The data are partially confidental