The post was not intended to be content-rich, just my initial feedback
after only just switching to 2.6. Since I had largely given up on this
particular line of attack using 2.4 I didn't think to do a detailed analysis
at this time. I was also hoping that others would add to the discussion.
As this could become important I will be doing more analysis, but due to
the nature of the issue and trying to keep as many factors constant as
possible, this may take some time.
On 2 Apr 2004 at 1:32, Tom Lane wrote:
> "Gary Doades" <[EMAIL PROTECTED]> writes:
> > As a test in PosgreSQL I issued a statement to update a single column
> > of a table containing 2.8 million rows with the values of a column in
> > a table with similar rowcount. Using the above spec I had to stop the
> > server after 17 hours. The poor thing was thrashing the hard disk and
> > doing more swapping than useful work.
> This statement is pretty much content-free, since you did not show us
> the table schemas, the query, or the EXPLAIN output for the query.
> (I'll forgive you the lack of EXPLAIN ANALYZE, but you could easily
> have provided all the other hard facts.) There's really no way to tell
> where the bottleneck is. Maybe it's a kernel-level issue, but I would
> not bet on that without more evidence. I'd definitely not bet on it
> without direct confirmation that the same query plan was used in both
> regards, tom lane
> Incoming mail is certified Virus Free.
> Checked by AVG Anti-Virus (http://www.grisoft.com).
> Version: 7.0.230 / Virus Database: 262.6.5 - Release Date: 31/03/2004
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match