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) (actual
Re: Mark Felder 2013-05-13 op.ww1gv9fd34t...@markf.office.supranet.net
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
On Tue, May 14, 2013 at 11:52:29PM -0700, Christoph Berg wrote:
Re: Mark Felder 2013-05-13 op.ww1gv9fd34t...@markf.office.supranet.net
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
Hi!
This has been a pain point for quite a while. While we've had several
discussions in the area, it always seems to just kinda trail off and
eventually vanish every time it comes up.
A really basic example of how bad the planner is here:
CREATE TABLE foo AS
SELECT a.id, a.id % 1000 AS
On 15.05.2013 18:31, Shaun Thomas wrote:
I've seen conversations on this since at least 2005. There were even
proposed patches every once in a while, but never any consensus. Anyone
care to comment?
Well, as you said, there has never been any consensus.
There are basically two pieces to the
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas stho...@optionshouse.comwrote:
[Inefficient plans for correlated columns] has been a pain point for quite
a while. While we've had several discussions in the area, it always seems
to just kinda trail off and eventually vanish every time it comes
On 05/15/2013 10:52 AM, Heikki Linnakangas wrote:
I think it would be pretty straightforward to use such a statistic,
once we have it. So perhaps we should get started by allowing the DBA
to set a correlation metric manually, and use that in the planner.
The planner already kinda does this
On 05/15/2013 12:23 PM, Craig James wrote:
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas
stho...@optionshouse.com mailto:stho...@optionshouse.com wrote:
[Inefficient plans for correlated columns] has been a pain point
for quite a while. While we've had several discussions in the
On Wed, May 15, 2013 at 11:52 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.05.2013 18:31, Shaun Thomas wrote:
I've seen conversations on this since at least 2005. There were even
proposed patches every once in a while, but never any consensus. Anyone
care to comment?
Well,
On Tue, Jan 22, 2013 at 3:57 PM, Виктор Егоров vyego...@gmail.com wrote:
Greetings.
I've been playing with a small query that I've been asked to optimize
and noticed a strange (for me) effect.
Query uses this table:
Table clc06_tiles
Column |
On Wed, May 15, 2013 at 01:30:57PM -0400, Nikolas Everett wrote:
The option that always made the most sense to me was having folks ask
postgres to collect the statistic by running some command that marks two
columns as correlated. This could at least be a starting point.
One suggestion made
On 16/05/13 04:23, Craig James wrote:
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas
stho...@optionshouse.com mailto:stho...@optionshouse.com wrote:
[Inefficient plans for correlated columns] has been a pain point
for quite a while. While we've had several discussions in the
area,
2013/5/15 Robert Haas robertmh...@gmail.com
Original query looks like this ( http://explain.depesz.com/s/pzv ):
After a while I added row_number() to the inner part (
http://explain.depesz.com/s/hfs ):
It was really surprising to see a side effect of 8x performance boost.
The only
On 16/05/13 03:52, Heikki Linnakangas wrote:
On 15.05.2013 18:31, Shaun Thomas wrote:
I've seen conversations on this since at least 2005. There were even
proposed patches every once in a while, but never any consensus. Anyone
care to comment?
Well, as you said, there has never been any
Shaun Thomas wrote on 15.05.2013 17:31:
Hi!
This has been a pain point for quite a while. While we've had several
discussions in the area, it always seems to just kinda trail off and
eventually vanish every time it comes up.
A really basic example of how bad the planner is here:
CREATE TABLE
On Wed, May 15, 2013 at 1:15 PM, Gavin Flower gavinflo...@archidevsys.co.nz
wrote:
On 16/05/13 04:23, Craig James wrote:
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas stho...@optionshouse.comwrote:
[Inefficient plans for correlated columns] has been a pain point for
quite a while. While
16 matches
Mail list logo