> There are a number of ways you can (indirectly) see how far it has got.
> If it's in the first phase (the seq scan), by looking at which file it
> has open you should be able to see how far along the table it is. Once
> it's in the sort stage you should be able to see from the tape files
> approi
On Thu, May 04, 2006 at 10:09:33AM +0200, Csaba Nagy wrote:
> Well, I guess that's it then... I will let the query run with the
> seqscan+sort. It will still run 1-2 days, yesterday I stopped it after 6
> hours ;-) Actually it would be nice to have some kind of feedback on
> what is it doing so I c
> > Looks that way to me. You could try setting enable_sort off as well,
> > which will penalize the seqscan+sort plan another 100million cost units.
> > And maybe try reducing random_page_cost to make the indexscan look
> > cheaper. However, if there's a 100million delta between the two plans,
>
am 03.05.2006, um 20:20:55 +0200 mailte Florian G. Pflug folgendes:
> >of the index scan ? The table is quite big, might be possible. I still
> >wonder why would be seqscan+sort faster than index scan... the sort will
> >for sure have to write to disk too given the size of the table...
>
> When u
On Wed, 2006-05-03 at 13:34, Tom Lane wrote:
> Csaba Nagy <[EMAIL PROTECTED]> writes:
> > OK, maybe that's the point... the "cost bust" given to the sequential
> > scan by enable_seqscan=off is not enough in this case to exceed the cost
> > of the index scan ?
>
> Looks that way to me. You could
Csaba Nagy <[EMAIL PROTECTED]> writes:
> OK, maybe that's the point... the "cost bust" given to the sequential
> scan by enable_seqscan=off is not enough in this case to exceed the cost
> of the index scan ?
Looks that way to me. You could try setting enable_sort off as well,
which will penalize
Csaba Nagy wrote:
Docs say:
Enables or disables the query planner's use of sequential scan plan
types. It's not possible to suppress sequential scans entirely, but
turning this variable off discourages the planner from using one if
there are other methods available.
Note the second sentence.
On Wed, May 03, 2006 at 06:42:00PM +0200, Csaba Nagy wrote:
> OK, maybe that's the point... the "cost bust" given to the sequential
> scan by enable_seqscan=off is not enough in this case to exceed the cost
> of the index scan ? The table is quite big, might be possible. I still
> wonder why would
> Docs say:
>
> > Enables or disables the query planner's use of sequential scan plan
> > types. It's not possible to suppress sequential scans entirely, but
> > turning this variable off discourages the planner from using one if
> > there are other methods available.
>
> Note the second sente
But I also asked for _ordered_ results, which the seq scan is not
covering, but the index does... and I specifically disabled sequential
scan.
Docs say:
Enables or disables the query planner's use of sequential scan plan
types. It's not possible to suppress sequential scans entirely, but
turn
> Without a WHERE you get the whole table.
>
> A Index-Scan is, in this case, expensive.
I know that, and I would agree if I wouldn't have asked for _ordered_
result, and wouldn't have turned enable_seqscan=off.
In these conditions I would have expected an index scan, even if it is
more expensi
On Wed, 2006-05-03 at 17:48, John D. Burger wrote:
> Csaba Nagy wrote:
>
> > select * from table order by col_1;
> >
> > Isn't it supposed to choose the index scan at least when
> > enable_seqscan=off ? Even if it is indeed not faster to do the index
> > scan than seqscan+sort.
>
> I think becaus
Csaba Nagy <[EMAIL PROTECTED]> schrieb:
> select * from table order by col_1;
Without a WHERE you get the whole table.
A Index-Scan is, in this case, expensive.
HTH, Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.
Csaba Nagy wrote:
select * from table order by col_1;
Isn't it supposed to choose the index scan at least when
enable_seqscan=off ? Even if it is indeed not faster to do the index
scan than seqscan+sort.
I think because you've asked for every row, it's going to have to scan
the whole table a
14 matches
Mail list logo
