Robert Haas writes:
> Well, I do not understand this code in depth (can you tell?) but it
> seems to me that we are effectively computing the size of the inner
> relation in two different ways in two different parts of the code.
That's because we are considering two different definitions of the i
On Tue, May 29, 2012 at 12:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, but isn't this a case of the left hand not knowing what the right
>> hand is doing? I mean, somehow we have enough information to estimate
>> that the index scans on b{1,2,3} are going to produce 2 rows per
>> execut
Robert Haas writes:
> Hmm, but isn't this a case of the left hand not knowing what the right
> hand is doing? I mean, somehow we have enough information to estimate
> that the index scans on b{1,2,3} are going to produce 2 rows per
> execution, but having figured that out (correctly) we then proc
On Mon, May 28, 2012 at 6:37 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> On Mon, May 28, 2012 at 11:23 PM, Tom Lane wrote:
>>> However, the error in your original example is far too large to be
>>> explained by that, so I think it was tripping over something different.
>
>> Good point. But I
On Tue, May 29, 2012 at 1:37 AM, Tom Lane wrote:
> So, nothing to see here ... 8.4 is just not very good with this type
> of problem.
Fair enough, thanks for your time. :)
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Marti Raudsepp writes:
> On Mon, May 28, 2012 at 11:23 PM, Tom Lane wrote:
>> However, the error in your original example is far too large to be
>> explained by that, so I think it was tripping over something different.
> Good point. But I generated a bigger data set with the above test case
> a
On Mon, May 28, 2012 at 11:23 PM, Tom Lane wrote:
> However, the error in your original example is far too large to be
> explained by that, so I think it was tripping over something different.
Good point. But I generated a bigger data set with the above test case
and it gets progressively worse w
Marti Raudsepp writes:
> On Mon, May 28, 2012 at 10:32 PM, Marti Raudsepp wrote:
>> There was a similar case in 9.0.4 with WHERE i=1, but that has been
>> fixed in 9.0.7
> Oh, it's been fixed in 9.0.7, but apparently not in 8.4.11; the empty
> parent tables are confusing the estimate:
Hmm ... w
On Mon, May 28, 2012 at 10:32 PM, Marti Raudsepp wrote:
> There was a similar case in 9.0.4 with WHERE i=1, but that has been
> fixed in 9.0.7
Oh, it's been fixed in 9.0.7, but apparently not in 8.4.11; the empty
parent tables are confusing the estimate:
explain select * from a_parent join b_par
On Mon, May 28, 2012 at 8:56 PM, Tom Lane wrote:
> Also, what do you have constraint_exclusion set to?
The only sane value, "partition"
> This sounds familiar, but a quick trawl through the commit logs didn't
> immediately turn up any related-looking patches. Can you put together
> a self-conta
Marti Raudsepp writes:
> This bug isn't causing me any immediate problems -- the plan works out
> well regardless -- but PostgreSQL 8.4.7 is somehow overestimating the
> number of rows coming from a nestloop join, when joining 2 large
> partitioned tables.
This sounds familiar, but a quick trawl
On Mon, May 28, 2012 at 10:45 AM, Marti Raudsepp wrote:
> Query:
> SELECT '2012-05-28T09:00:00', count(*),
> uniq(sort(array_agg(visitor_id))), banner_id, client_body_id,
> partner_body_id, space_id, campaign_id, evt_type_id FROM stats_request
> WHERE stats_request.request_time >= '2012-05-28T09:0
Hi list,
This bug isn't causing me any immediate problems -- the plan works out
well regardless -- but PostgreSQL 8.4.7 is somehow overestimating the
number of rows coming from a nestloop join, when joining 2 large
partitioned tables. Maybe it's been fixed in more recent versions,
sadly it's an EO
13 matches
Mail list logo
