I found one query that did a seqscan anyway(with enable_seqscan off),
because doing an index scan would be more than 1M points more
expensive (to the planner).
Hmm, i guess that says it all :)
--
Patriotism is the conviction that your country is superior to all
others because you were born in
Hi,
Sorry for the late answer.
I found the query i was looking for in the log (duration) and could
prove that the seqscan is faster if the data were not cached.
This particular one was 22% faster.
It is a query which will get turned into a nested loop index scan for
a lot of rows, on a huge
On Fri, Aug 27, 2010 at 1:57 PM, Scott Marlowe scott.marl...@gmail.com wrote:
On Thu, Aug 26, 2010 at 4:32 AM, Willy-Bas Loos willy...@gmail.com wrote:
Hi,
I have a colleague that is convinced that the website is faster if
enable_seqscan is turned OFF.
I'm convinced of the opposite (better
On Thu, Aug 26, 2010 at 6:32 AM, Willy-Bas Loos willy...@gmail.com wrote:
I have a colleague that is convinced that the website is faster if
enable_seqscan is turned OFF.
I'm convinced of the opposite (better to leave it ON), but i would like to
show it, prove it to him.
Now the first query
@Pierre: i know.. but first i'd have to find such a query from real-life.
And also, i'm convinced that this query would be faster with a seqscan if
the data wenen't cached.
@Arjen: thanks, that helps.
But that's only the OS cache. There's also the shared_buffers, which are a
postgres specific
Willy-Bas Loos wrote:
But that's only the OS cache. There's also the shared_buffers, which
are a postgres specific thing.
I've found DISCARD in the manual
http://www.postgresql.org/docs/8.3/interactive/sql-discard.html, but
that only influences a single session, not the shared buffers.
I
On Thu, Aug 26, 2010 at 4:32 AM, Willy-Bas Loos willy...@gmail.com wrote:
Hi,
I have a colleague that is convinced that the website is faster if
enable_seqscan is turned OFF.
I'm convinced of the opposite (better to leave it ON), but i would like to
show it, prove it to him.
Stop, you're
Hi,
I have a colleague that is convinced that the website is faster if
enable_seqscan is turned OFF.
I'm convinced of the opposite (better to leave it ON), but i would like to
show it, prove it to him.
Now the first query we tried, would do a bitmap heap scan instead of a
seqscan when the latter
Isn't it more fair to just flush the cache before doing each of the
queries? In real-life, you'll also have disk caching... Flushing the
buffer pool is easy, just restart PostgreSQL (or perhaps there is a
admin command for it too?). Flushing the OS-disk cache is obviously
OS-dependent, for
The bitmap heap scan is 3% faster,
3% isn't really significant. Especially if the new setting makes one query
100 times slower... Like a query which will, by bad luck, get turned into
a nested loop index scan for a lot of rows, on a huge table which isn't in
cache...
--
Sent via
10 matches
Mail list logo
