What's the problem? You are joining two 300 million row tables in 0.15
of a second - seems reasonable.
Dmitri
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Amit V Shah
> Sent: Thursday, December 08, 2005 11:59 AM
> To: 'pgsql-performance@post
That seems like a pretty horrible way to do that query, given the table sizes.
What about something like:
SELECT count(*)
FROM fotos f
LEFT JOIN archivo a USING(archivo)
WHERE a.archivo IS NULL
Incidentally, can someone explain what the "Materialize" subplan does? Is this
new in 8.1?
Dmitri
I was wondering - have you had a chance to run the same benchmarks on
ReiserFS (ideally both 3 and 4, with notail)?
I'd be quite interested to see how it performs in this situation since
it's my fs of choice for most things.
Thanks,
Dmitri
-Original Message-
From: [EMAIL PROTECTED]
[mail
I'd say it's a little early to worry about a 10% performance increase
when you don't have any redundancy. You might want to consider using
more, cheaper SATA disks - with more spindles you may very well get
better performance in addition to redundancy.
Anyway, here's an optimization project I jus
Hi,
The article seems to dismiss RAID5 a little too quickly. For many
application types, using fast striped mirrors for the index space and
RAID5 for the data can offer quite good performance (provided a
sufficient number of spindles for the RAID5 - 5 or 6 disks or more). In
fact, random read (i
