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
Hi,
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 integer,
i4 integer,
i5 integer,
d1 date,
d2 date,
d3 date,
PRIMAR
14 matches
Mail list logo
