On Wed, May 15, 2013 at 1:15 PM, Gavin Flower wrote:
> On 16/05/13 04:23, Craig James wrote:
>
> On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas wrote:
>
>> [Inefficient plans for correlated columns] has been a pain point for
>> quite a while. While we've had several discussions in the area, it al
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 f
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 consen
2013/5/15 Robert Haas
> > 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 differe
On 16/05/13 04:23, Craig James wrote:
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas
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, it always seems to just k
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 Tue, Jan 22, 2013 at 3:57 PM, Виктор Егоров 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 | Type
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?
On 05/15/2013 12:23 PM, Craig James wrote:
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas
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, it always seems to
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 wit
On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas wrote:
> [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 up.
>
> ...
> Since ther
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 pu
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 col_
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
>
14 matches
Mail list logo