Hello,
I just upgraded with pg_dump/restore from PostgreSQL 8.3.11 to 8.4.4 but
I'm having major performance problems with a query with many left joins.
Problem is that costs are now very, very, very high (was ok in 8.3).
Analyze has been done. Indexes are of course there.
-> Merge Left J
Greg Smith wrote:
He's been seeing >75GB/s of aggregate memory bandwidth out of that
monster--using gcc, so even at a disadvantage compared to the Intel
one used for that report.
On second read this was confusing. The best STREAM results from using
the Intel compiler on Linux. The ones I've
Jose Ildefonso Camargo Tolosa wrote:
Also, nowadays, Intel has better performance than AMD, at least when
comparing Athlon 64 vs Core2, I'm still saving to get a Phenom II
system in order to benchmark them and see how it goes (does anyone
have one of these for testing?).
Things even out agai
Hello
if you read a some longer field - longer than 2Kb, then PostgreSQL has
to read this value from a table_toast file. see
http://developer.postgresql.org/pgdocs/postgres/storage-toast.html -
and reading have to be slower than you don't read this field.
Regards
Pavel Stehule
2010/8/29 Volodym
I don't clearly understand why this happens, but when I try join some
tables using arrays I end up with:
=# explain select count(*) from urls JOIN rules ON urls.tag && rules.tag;
QUERY PLAN
-
Hi!
On Fri, Aug 27, 2010 at 12:55 PM, Greg Smith wrote:
> Scott Carey wrote:
>>
>> But the select count(*) query, cached in RAM is 3x faster in one system
>> than the other. The CPUs aren't 3x different performance wise. Something
>> else may be wrong here.
>>
>> An individual Core2 Duo 2.93Ghz
