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.
Cheers,
Gary.
On 2 Apr 2004 at 1:32, Tom Lane wrote:
> "Gary Doades" <gpd@gpdnet.co.uk> 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 (http://www.grisoft.com).
> Version: 7.0.230 / Virus Database: 262.6.5 - Release Date: 31/03/2004
>