I fully agree with Gaetano about testing sync methods. From testing I've done
on two different Solaris 8 boxes, the O_DSYNC option on Solaris 8 beats fsync
and fdatasync easily. Test it yourself though. There's probably some
opportuntiy there for better performance for you.
> > BTW this is Post
Ok.. now I ran "VACUUM FULL' and things seem to be working as they should..
explain analyze select * from history where date='2004-09-07' and stock='MSFT';
Seq Scan on island_history (cost=0.00..275359.13 rows=292274
width=83) (actual time=50.000..411683.000 rows=265632 loops=1)
Filter: ((dat
Mischa Sandberg wrote:
In the meantime, what I gather from browsing mail archives is that
postgresql on Solaris seems to get hung up on IO rather than CPU.
Furthermore, I notice that Oracle and now MySQL use directio to bypass
the system cache, when doing heavy writes to the disk; and Postgresql
On Thu, 16 Sep 2004 20:51:11 -0500, Stephen Crowley
<[EMAIL PROTECTED]> wrote:
>explain analyze select * from history where date='2004-09-07' and
>stock='ORCL' LIMIT 10;
>" -> Index Scan using island_history_date_stock_time on
>island_history (cost=0.00..183099.72 rows=102166 width=83) (actual
> Iain
> Joe's example wasn't excluding partions, as he didn't use a
> predicated UNION
> ALL view to select from. His queries use an indexed column that allow the
> various partitions to be probed at low cost, and he was satisfied
> wth that.
Agreed - very very interesting design though.
> My po
