- Forwarded Message -
>From: Denis de Bernardy
>To: Jens Hoffrichter
>Sent: Tuesday, June 28, 2011 12:59 AM
>Subject: Re: [PERFORM] Getting rid of a seq scan in query on a large table
>
>
>> Hash Cond: (posts.poster_id = posters.poster_id)
>
>>
[big nestloop with a huge number of rows]
You're in an edge case, and I doubt you'll get things to run much faster: you
want the last 1k rows out of an 18M row result set... It will be slow no matter
what you do.
What the plan is currently doing, is it's going through these 18M rows using a
fo
I might have misread, but:
> select * from connections where locked_by <> 4711
> union all
> select * from connections_locked where locked_by = 4711;
The first part will result in a seq scan irrespective of indexes, and the
second has no index on locked_by. The best you can do is to eliminate t
- Original Message -
> From: Josh Berkus
> To: postgres performance list
> Cc:
> Sent: Thursday, May 5, 2011 2:02 AM
> Subject: Re: [PERFORM] amazon ec2
> So memcached basically replaces the filesystem?
>
> That sounds cool, but I'm wondering if it's actually a performance
> speedup.
> - Original Message -
>> From: Tom Lane
>> To: Denis de Bernardy
>> Cc: "pgsql-performance@postgresql.org"
>
>> Sent: Wednesday, May 4, 2011 4:12 PM
>> Subject: Re: [PERFORM] row estimate very wrong for array type
>>
>>
understanding of the PG internals to
massage pre-existing code... Feel free to message me off list with pointers if
you think I might be able to help.
- Original Message -
> From: Tom Lane
> To: Denis de Bernardy
> Cc: "pgsql-performance@postgresql.org"
> Sent: Wednesda
Hi,
I'm running into erroneous row estimates when using an array type, and I'm
running out of ideas on how to steer postgres into the right direction... I've
tried setting statistics to 1000, vacuuming and analyzing over and over,
rewriting the query differently... to no avail.
The table looks
