Hi,
After few test, the difference is explained by the
effective_cache_size parameter.
with effective_cache_size=1000 (default)
the planner chooses the following plan
postgres=# explain select count(*) from (select distinct on (val) *
from test) as foo;
Q
What "same result"? You only ran it up to 2K rows, not 2M. In any
Sorry, I do this over and over until xxx.000 rows but I do not write
in the mail.
I do it again. initdb, create table, insert, vacuum full analyze,
explain analyze at each stage.
And there was no problem.
So I make a copy
Steinar H. Gunderson wrote:
> On Thu, Nov 24, 2005 at 09:15:44PM -0600, Kyle Cordes wrote:
> > I have hit cases where I have a query for which there is a somewhat
> > "obvious" (to a human...) query plan that should make it possible to get
> > a query answer pretty quickly. Yet the query "never"
On Thu, Nov 24, 2005 at 09:15:44PM -0600, Kyle Cordes wrote:
> I have hit cases where I have a query for which there is a somewhat
> "obvious" (to a human...) query plan that should make it possible to get
> a query answer pretty quickly. Yet the query "never" finishes (or
> rather, after hours
Tom Lane wrote:
What "same result"? You only ran it up to 2K rows, not 2M. In any
case, EXPLAIN without ANALYZE is pretty poor ammunition for complaining
that the planner made the wrong choice. I ran the same
Hello, sorry to jump in mid-stream, but this reminded me of something.
I have h
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
> I redo the test, with a freshly installed data directory. Same result.
What "same result"? You only ran it up to 2K rows, not 2M. In any
case, EXPLAIN without ANALYZE is pretty poor ammunition for complaining
that the planner made the wrong cho
I redo the test, with a freshly installed data directory. Same result.
Note: This is the full log. I just suppress the mistake I do like
"sl" for "ls".
Jean-Gérard Pailloncy
Last login: Thu Nov 24 12:52:32 2005 from 192.168.0.1
OpenBSD 3.8 (WDT) #2: Tue Nov 8 00:52:38 CET 2005
Welcome to
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
Why the stupid indexscan plan on the whole table ?
Pray tell, what are you using for the planner cost parameters?
The only way I can come close to duplicating your numbers is
by setting random_page_cost to somewhere around 0.01 ...
I did not
THIS MAY SEEM SILLY but vacuum is mispelled below and presumably
there was never any ANALYZE done.
postgres=# vaccum full verbose analyze;
I do have done the "vacUUm full verbose analyze;".
But I copy/paste the wrong line.
Cordialement,
Jean-Gérard Pailloncy
---(en
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> wrote ..
[snip]
THIS MAY SEEM SILLY but vacuum is mispelled below and presumably there was
never any ANALYZE done.
>
> postgres=# vaccum full verbose analyze;
---(end of broadcast)---
TIP 3: Have you che
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
> Why the stupid indexscan plan on the whole table ?
Pray tell, what are you using for the planner cost parameters?
The only way I can come close to duplicating your numbers is
by setting random_page_cost to somewhere around 0.01 ...
11 matches
Mail list logo
