Hi,
I have two similar queries that calculate "group by" summaries over a huge
table (74.6mil rows).
The only difference between two queries is the number of columns that group by
is performed on.
This difference is causing two different plans which are vary so very much in
performance.
Postgres
t8 can accomodate 64 flags - the space saving can be
substantial.
Thanks,
-Slava.
- Original Message -
From: "Scott Marlowe"
To: "Slava Moudry"
Cc: "Robert Haas" ;
Sent: Thursday, August 20, 2009 6:58 PM
Subject: Re: [PERFORM] number of rows estimation
s for the
next patch/release.
Btw, can you send me the link to " PG's selectivity estimator" discussion - I'd
like to provide feedback if I can.
Thanks,
-Slava.
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Thursday, August 20, 2009 1
essage-
From: Scott Marlowe [mailto:scott.marl...@gmail.com]
Sent: Tuesday, August 18, 2009 2:58 PM
To: Slava Moudry
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] number of rows estimation for bit-AND operation
2009/8/18 Slava Moudry :
> Hi Scott,
> Thank you for reply.
>
I could/should report as a bug? I've been
struggling with this issue in 8.2, 8.3.x (now using 8.4.0).
We can more or less work around this by disabling nestloop in our analytics
queries but I have problems enforcing this in reporting applications.
Thanks,
-Slava Moudry.
-
s plan with Nested Loops for
other queries. I can fix it by setting enable_nest_loops to off, but it's not
something I should set for all queries.
Is there any way to help Postgres make a better estimation for number of rows
returned by bit function?
Thanks,
-Slava Moudry, Senior DW Engineer.
