Re: [PERFORM] RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1

2013-05-15 Thread Christoph Berg
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: [PERFORM] RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1

2013-05-15 Thread Christoph Berg
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

Re: [PERFORM] RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1

2013-05-15 Thread k...@rice.edu
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

[PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Shaun Thomas
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Heikki Linnakangas
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Craig James
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Shaun Thomas
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Andrew Dunstan
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Nikolas Everett
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,

Re: [PERFORM] Effect of the WindowAgg on the Nested Loop

2013-05-15 Thread Robert Haas
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 |

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread eggyknap
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Gavin Flower
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,

Re: [PERFORM] Effect of the WindowAgg on the Nested Loop

2013-05-15 Thread Victor Yegorov
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Gavin Flower
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Thomas Kellerer
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

Re: [PERFORM] Thinking About Correlated Columns (again)

2013-05-15 Thread Craig James
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