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
> setups.
>                       regards, tom lane
> -- 
> Incoming mail is certified Virus Free.
> Checked by AVG Anti-Virus (
> 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

Reply via email to