On Sat, Jun 14, 2008 at 02:35:38PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I created a test case that has close to the same estimated and
> > actual row counts and has the same plan if I disable enable_nestloop:
>
> There's something weird about this --- why does the
Hi Michael.
Thank you for your answer. I've checked - enable_nestloop is true. I did
ANALYZE, but that didn't help. The sequential scan is still used Any
more ideas why?
Julius Tuskenis
Michael Fuhr rašė:
On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
Julius T
Hello, Tom.
So I think the OP's
problem is purely a statistical one, or maybe he's in a situation where
he should reduce random_page_cost.)
What could be done solving that "statistical problem"? :) Current value
for random_page_cost is 4. What value would you suggest?
Julius Tuskenis
-
Michael Fuhr <[EMAIL PROTECTED]> schrieb:
> On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
> > Julius Tuskenis <[EMAIL PROTECTED]> schrieb:
> > > I have a question concerning performance. One of my queries take a long
> > > to execute. I tried to do "explain analyse" and I s
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I created a test case that has close to the same estimated and
> actual row counts and has the same plan if I disable enable_nestloop:
There's something weird about this --- why does the second plan seqscan
b_saskaita, instead of using the bitmap scan tha
On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
> Julius Tuskenis <[EMAIL PROTECTED]> schrieb:
> > I have a question concerning performance. One of my queries take a long
> > to execute. I tried to do "explain analyse" and I see that the
> > sequential scan is being used, al
Julius Tuskenis <[EMAIL PROTECTED]> schrieb:
> Hello.
>
> I have a question concerning performance. One of my queries take a long
> to execute. I tried to do "explain analyse" and I see that the
> sequential scan is being used, although I have indexes set on columns
> that are used in joins.
Hello.
I have a question concerning performance. One of my queries take a long
to execute. I tried to do "explain analyse" and I see that the
sequential scan is being used, although I have indexes set on columns
that are used in joins. The question is - WHY, and how to change that
behavior???
On Wed, 27 Apr 2005 00:28:18 -0700, John Barham <[EMAIL PROTECTED]> wrote:
> test=# create table tt (id serial unique, s varchar);
> [populate tt w/ 10 rows]
> test=# insert into tt (s) values ('foo');
> test=# select currval('tt_id_seq');
> currval
> -
> 12
> (1 row)
> test=# ex
test=# create table tt (id serial unique, s varchar);
[populate tt w/ 10 rows]
test=# insert into tt (s) values ('foo');
test=# select currval('tt_id_seq');
currval
-
12
(1 row)
test=# explain select s from tt where id = 12;
QUERY PLAN
---
> test=# explain select s from tt where id = currval('tt_id_key');
> QUERY PLAN
> --
> Seq Scan on tt (cost=0.00..1734.42 rows=1 width=32)
>Filter: (id = currval('tt_id_key'::text))
> (2 rows)
should be:
test=# explai
On Thu, Aug 16, 2001 at 08:10:41PM -0400, [EMAIL PROTECTED] wrote:
> Ok I set enable_hashjoin and enable_mergejoin to off
> and performance is much much worse: just over 1 second
> job becomes a minute job
>
> Perhaps I should re-check if the database
> gets bigger.
>
> Thanks a lot
>
> On Thu,
Two estimates I undestand are quite
good.
select distinct id on body_index where string='book'
returns about 1500 rows. That matches with
the bottom line of the plan
There are 5139 rows in table item. It is
the same number of rows in the plan for
sequential scan
If I were doing a maual join
[EMAIL PROTECTED] writes:
> Can someone explain why pg is doing
> a sequential scan on table item with the following
> statement
Looks like a fairly reasonable plan to me, if the rows estimates are
accurate. Are they?
regards, tom lane
---(end of
Can someone explain why pg is doing
a sequential scan on table item with the following
statement
-
q=> explain select distinct h.id,i.item,i.heading,i.finish from item i ,body_index h
where h.id=i.item and (h.string='book') order by finish;
NOTICE: QUERY PLAN:
Unique (cost=6591.46..6606.5
15 matches
Mail list logo
