On 05/02/11 08:11, Tom Lane wrote:
Wayne Conrad writes:
On 04/29/11 12:12, Kevin Grittner wrote:
Out of curiosity, what do you get with?:
explain analyze
select
page_number,
ps_id,
ps_page_id
from ps_page p
where exists
(
select * from documents_ps_page d
where d.ps_page_id = p.ps_page_id
Replying to the list this time (oops)...
On 04/29/11 12:33, Kevin Grittner wrote:
Also, make sure that you run ANALYZE against your temp table right
before running your query.
I did that, and also added an index to it. That had no effect on the
run time, but did fix the estimate for the temp
Howdy. We've got a query that takes less than a second unless we add a
"order by" to it, after which it takes 40 seconds. Here's the query:
select page_number, ps_id, ps_page_id from ps_page where ps_page_id in
(select ps_page_id from documents_ps_page where document_id in (select
document_i
On 03/04/11 10:34, Glyn Astill wrote:
> I'm wondering (and this may be a can of worms) what peoples opinions
are on these schedulers?
When testing our new DB box just last month, we saw a big improvement in
bonnie++ random I/O rates when using the noop scheduler instead of cfq
(or any other).
10 minutes or so. The server those came
off of has less RAM and disks than yours, so you'll fit larger database
scales into memory before performance falls off, but that gives you
something to compare against.
TCB-B-like tests, will do.
Greg, Thanks a million.
Wayne Conrad
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
We're building a new database box. With the help of Gregory Smith's
book, we're benchmarking the box: We want to know that we've set it up
right, we want numbers to go back to if we have trouble later, and we
want something to compare our _next_ box against. What I'd like to know
is, are the
On Tue, 14 Jul 2009, Scott Marlowe wrote:
Are you guys doing anything that could be deemed pathological, like
full table updates on big tables over and over? Had an issue last
year where a dev left a where clause off an update to a field in one
of our biggest tables and in a few weeks the databa
On Tue, 14 Jul 2009, Scott Marlowe wrote:
Just wondering, which pgsql version, and also, do you have
autovacuum turned on?
Dang, I should have said in my initial message. 8.3.6, and autovacuum
is turned on and has plenty of log activity.
--
Sent via pgsql-performance mailing list (pgsql-perfo
Ouch hurts my eyes :) Can you see something like table_len,
dead_tuple_percent, free_percent order by dead_tuple_percent desc
limit 10 or something like that maybe?
Sorry about the pain. Didn't know what you needed to see.
Ordering by dead_tuple_percent:
db.production=> select table_name, ta
e for restoring performance other than VACUUM
FULL/REINDEX DATABASE?
Before trying any fix, what data do I want to collect that might
indicate where the performance problem is?
Best Regards,
Wayne Conrad
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
10 matches
Mail list logo
