On 5/7/08, Tarcizio Bini <[EMAIL PROTECTED]> wrote:
> I'm working on optimizing queries using the Kruskal algorithm
> (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4318118).
That paper looks very interesting. I would love to hear what the
PostgreSQL committers think of this algorithm.
Ale
Hello friends,
I'm working on optimizing queries using the Kruskal algorithm (
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4318118). I did several
tests in the database itself and saw interesting results.
I did 10 executions with each query using unchanged source of Postgres and
then adap
1) RAID1+0 to make one big volume
2) RAID1 for OS/apps/etc, RAID1 for database
3) RAID1 for OS+xlog, RAID1 for database
4) RAID1 for OS+popular tables, RAID1 for rest of database
Lots of good info, thanks for all the replies. It seems to me then,
that the speed increase you'd get from raid0
On Tue, 6 May 2008, Craig James wrote:
I/O Sched AVG Test1 Test2
--- -
cfq705 695715
noop 758 769747
deadline 741 705775
anticipatory 494 477511
Interesting. That contrasts with some tests I
On Tue, 6 May 2008, Tom Lane wrote:
If a misestimate of this kind is bugging you enough that you're willing
to change the query, I think you can fix it like this:
select ... from foo order by x limit n;
=>
select ... from (select ... from foo order by x) ss limit n;
The subselec
Craig James wrote:
> This data is good enough for what I'm doing. There were
> reports from non-RAID users that the I/O scheduling could
> make as much as a 4x difference in performance (which makes
> sense for non-RAID), but these tests show me that three of
> the four I/O schedulers are with
If a misestimate of this kind is bugging you enough that you're
willing
to change the query, I think you can fix it like this:
select ... from foo order by x limit n;
=>
select ... from (select ... from foo order by x) ss limit n;
The subselect will be planned without awarene
