(Please don't top-post. )
Adrian Demaestri skrev:
> */Jeff Davis <[EMAIL PROTECTED]>/* escribió:
>
> On Mon, 2007-10-22 at 19:24 -0700, Adrian Demaestri wrote:
> > Hi,
> > I think planner should use other plans than seqscan to solve querys
> > like select * from hugetable limit 1,
John Major skrev:
> Hello Nis-
>
> I did reset the defaults before running the explain.
This line from your original post:
-> Seq Scan on sequence_alignment sa (cost=1.00..110379294.60
rows=467042560 width=4)
Is an indication that you didn't (AFAIK enable_seqscan=off works by
setting
John Major skrev:
> I am trying to join three quite large tables, and the query is
> unbearably slow(meaning I can't get results in more than a day of
> processing).
> I've tried the basic optimizations I understand, and nothing has
> improved the execute speed any help with this would be great
Chris Kratz skrev:
> Hello Everyone,
>
> I'm struggling to get postgres to run a particular query quickly. It
> seems that very early on, the planner seems to mis-estimate the
> number of rows returned by a join which causes it to assume that
> there is only 1 row as it goes up the tree. It then
El-Lotso skrev:
> I'm on the verge of giving up... the schema seems simple and yet there's
> so much issues with it. Perhaps it's the layout of the data, I don't
> know. But based on the ordering/normalisation of the data and the one to
> many relationship of some tables, this is giving the planne
Tilmann Singer skrev:
> * Nis Jørgensen <[EMAIL PROTECTED]> [20070730 18:33]:
>> It seems to me the subselect plan would benefit quite a bit from not
>> returning all rows, but only the 10 latest for each user. I believe the
>> problem is similar to what is discussed
Tilmann Singer skrev:
> But the subselect is not fast for the user with many relationships and
> matched rows at the beginning of the sorted large_table:
>
> testdb=# EXPLAIN ANALYZE SELECT * FROM large_table lt
> WHERE user_id IN (SELECT contact_id FROM relationships WHERE
> user_id=5)
>
Tilmann Singer skrev:
> The query works fine for the common cases when matching rows are found
> early in the sorted large table, like this:
>
> testdb=# EXPLAIN ANALYZE
> SELECT * FROM large_table lt
> LEFT JOIN relationships r ON lt.user_id=r.contact_id
> WHERE r.user_id = 5 OR lt.user_id =
Karl Denninger skrev:
> I've got an interesting issue here that I'm running into with 8.2.3
>
> This is an application that has run quite well for a long time, and has
> been operating without significant changes (other than recompilation)
> since back in the early 7.x Postgres days. But now we'r
Vidhya Bondre skrev:
> Hi all,
>
>I need a very urgent help from you all in below case.
>
>I have a query
[snipped]
> after vacuuming the db it has become very very slow ... 100 times slow.
>
> Please suggest ?
Suggestions for getting more/better responses:
- Format your query ni
10 matches
Mail list logo
