From: | "Jeremy Haile" <jhaile(at)fastmail(dot)fm> |
---|---|
To: | "Chad Wagner" <chad(dot)wagner(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PG8.2.1 choosing slow seqscan over idx scan |
Date: | 2007-01-17 18:46:40 |
Message-ID: | 1169059600.23210.1169763553@webmail.messagingengine.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> It would be nice if the database could
> learn to estimate these values, as newer versions of Oracle does.
That would be really nice since it would take some of the guess work out
of it.
> Yes, cluster would rebuild the table for you. I wouldn't do anything too
> intrusive, run with the random_page_cost lowered, perhaps vacuum full,
> reindex, and see what happens.
I'll try doing the vacuum full and reindex tonight since they require
exclusive locks.
> Yep, my thoughts exactly. Partitioning support is PostgreSQL is there,
> but it needs a bit more of a tighter integration into the core (I shouldn't
> have to create a view, n tables, n rules, etc). Additionally, I have read
> that at some point when you have "y" partitions the performance degrades,
> haven't really looked into it myself.
Yeah - I haven't setup partitioning in PostgreSQL before, although I've
read quite a bit about it. I've talked about getting improved syntax
for partitioning in PostgreSQL. MySQL's syntax is much simpler and more
intuitive compared to setting them up with Postgres - it would be nice
if PostgreSQL adopted a similar syntax where partitions were first-class
citizens.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Haile | 2007-01-17 18:55:07 | Re: PG8.2.1 choosing slow seqscan over idx scan |
Previous Message | Scott Marlowe | 2007-01-17 18:35:11 | Re: PG8.2.1 choosing slow seqscan over idx scan |