On Tue, May 14, 2013 at 11:52:29PM -0700, Christoph Berg wrote:
> Re: Mark Felder 2013-05-13
> > What version of DBIx-SearchBuilder do you have on that server? The
> > RT guys usually recommend you have the latest possible so RT is
> > performing the most sane/optimized queries possible for your
>
Re: Mark Felder 2013-05-13
> What version of DBIx-SearchBuilder do you have on that server? The
> RT guys usually recommend you have the latest possible so RT is
> performing the most sane/optimized queries possible for your
> database. I honestly don't know if it will make a difference for
> you,
Re: Tom Lane 2013-05-06 <1583.1367858...@sss.pgh.pa.us>
> The newer rowcount estimates are much further away from reality:
>
> > Unique (cost=1117.67..1118.46 rows=9 width=1115) (actual
> > time=82.646..85.695 rows=439 loops=1)
>
> > Unique (cost=784205.94..796940.08 rows=145533 width=1061)
On Mon, May 13, 2013 at 4:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 13, 2013 at 4:14 PM, Tom Lane wrote:
>>> You know, of course, that the join size estimate isn't arrived at that
>>> way. Still, this point does make it seem more like a planner bug and
>>> less like bad input
Robert Haas writes:
> On Mon, May 13, 2013 at 4:14 PM, Tom Lane wrote:
>> You know, of course, that the join size estimate isn't arrived at that
>> way. Still, this point does make it seem more like a planner bug and
>> less like bad input stats. It would be nice to see a self-contained
>> exam
On Mon, May 13, 2013 at 4:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> The planner is estimating this the outer side of this nested loop will
>> produce 33 rows and that the inner side will produce 1. One would
>> assume that the row estimate for the join product couldn't be more
>> than 33 *
Robert Haas writes:
> The planner is estimating this the outer side of this nested loop will
> produce 33 rows and that the inner side will produce 1. One would
> assume that the row estimate for the join product couldn't be more
> than 33 * 1 = 33 rows, but the planner is estimating 62335 rows,
On Tue, 30 Apr 2013 06:20:55 -0500, Christoph Berg
wrote:
Hi,
this is more of a report than a question, because we thought this
would be interesting to share.
We recently (finally) migrated an Request Tracker 3.4 database running
on 8.1.19 to 9.2.4. The queries used by rt3.4 are sometimes wei
On Tue, Apr 30, 2013 at 7:20 AM, Christoph Berg
wrote:
>-> Nested Loop
> (cost=24.57..844.83 rows=62335 width=4) (actual time=0.109..0.633 rows=23
> loops=1)
> -> Bitmap Heap Scan
> o
Christoph Berg writes:
> We recently (finally) migrated an Request Tracker 3.4 database running
> on 8.1.19 to 9.2.4. The queries used by rt3.4 are sometimes weird, but
> 8.1 coped without too much tuning. The schema looks like this:
The newer rowcount estimates are much further away from reality
Hi,
this is more of a report than a question, because we thought this
would be interesting to share.
We recently (finally) migrated an Request Tracker 3.4 database running
on 8.1.19 to 9.2.4. The queries used by rt3.4 are sometimes weird, but
8.1 coped without too much tuning. The schema looks li
11 matches
Mail list logo
