Richard Huxton writes:
> Tom - does the planner/executor know it's got row estimates wrong? That
> is, if I'm not running an EXPLAIN ANALYSE is there a point at which we
> could log "planner estimate for X out by factor of Y"?
Not at the moment, but you could certainly imagine changing the exec
Tom Lane wrote:
Brian Herlihy <[EMAIL PROTECTED]> writes:
Before I go, I have a question - From discussions on the Postgresql irc
channel, and from reading the TODO list on the website, I am under the
impression that there are no plans to allow optimizer hints, such as "use index
table_pkey". I
Brian Herlihy <[EMAIL PROTECTED]> writes:
> Before I go, I have a question - From discussions on the Postgresql irc
> channel, and from reading the TODO list on the website, I am under the
> impression that there are no plans to allow optimizer hints, such as "use
> index
> table_pkey". Is this r
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Brian Herlihy <[EMAIL PROTECTED]> writes:
> > My options seem to be
> > - Fudge the analysis results so that the selectivity estimate changes. I
> > have tested reducing n_distinct, but this doesn't seem to help.
> > - Combine the columns into one col
Brian Herlihy <[EMAIL PROTECTED]> writes:
> My options seem to be
> - Fudge the analysis results so that the selectivity estimate changes. I
> have tested reducing n_distinct, but this doesn't seem to help.
> - Combine the columns into one column, allowing postgres to calculate the
> combined
--- Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > To: pgsql-performance@postgresql.org
> > Subject: Re: [PERFORM] Query planner is using wrong index.
> [Snip]
> > I am really surprised that I have to go through such contortions just
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:pgsql-performance-
> [EMAIL PROTECTED] On Behalf Of Brian Herlihy
> Sent: Thursday, April 06, 2006 6:56 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Query planner is using wrong index.
[S
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fös, 2006-04-07 at 00:01 +1000, Brian Herlihy wrote:
> > Index Scan using p2_p3_idx on t (cost=0.00..6.02 rows=1 width=102)
> (actual
> > time=2793.247..2793.247 rows=0 loops=1)
> >Index Cond: (((p2)::text = 'uk.altavista.com'::text) AND ((p3)::tex
On fös, 2006-04-07 at 00:01 +1000, Brian Herlihy wrote:
> --- Ragnar <[EMAIL PROTECTED]> wrote:
>
> > On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
> >
> > > Yes, the primary key is far better. I gave it the ultimate test - I
> > dropped
> > > the (p2, p3) index. It's blindingly fast
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
>
> > Yes, the primary key is far better. I gave it the ultimate test - I
> dropped
> > the (p2, p3) index. It's blindingly fast when using the PK,
>
> I have problems understanding exactly how an
On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
> --- Ragnar <[EMAIL PROTECTED]> wrote:
>
> > On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
> >
...
> > > PRIMARY KEY (p1, p2, p3)
...
> > >
> > > I have also created an index on (p2, p3), as some of my lookups are on
> > > these
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
>
> > I have a problem with the choice of index made by the query planner.
> >
> > My table looks like this:
> >
> > CREATE TABLE t
> > (
> > p1 varchar not null,
> > p2 varchar not null,
> >
On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
> I have a problem with the choice of index made by the query planner.
>
> My table looks like this:
>
> CREATE TABLE t
> (
> p1 varchar not null,
> p2 varchar not null,
> p3 varchar not null,
> i1 integer,
> i2 integer,
> i3 in
13 matches
Mail list logo
