Tom Lane writes:
The reason the planner does not much like this plan is that it's
estimating that quite a lot of rows will have to be hit in min_date_time
order before it finds enough rows with server_id = 21. Thus the high
cost estimate for the above step.
Thanks for the speedy and useful
Tom Lane writes:
That doesn't really tell me anything. What's the proportion of 21
records out of the total table?
Currently we have about 15 servers so 6% of the data is uniformly
distributed with the value 21.
create index fooi on foo (min_date_time) where server_id = 21;
This
Greg Stark writes:
Call it a wishlist bug. The problem is it would be a hard feature to
implement properly. And none of the people paid to work on postgres
by various companies seem to have this on their to-do lists. So
don't expect it in the near future.
We are using Postgres heavily, and we
It seems a simple vacuum (not full or analyze) slows down the
database dramatically. I am running vacuum every 15 minutes, but it
takes about 5 minutes to run even after a fresh import. Even with
vacuuming every 15 minutes, I'm not sure vacuuming is working
properly.
There are a lot of updates.
Shridhar Daithankar writes:
You should try 7.4 beta and pg_autovacuum which is a contrib module
in CVS tip.
It's on our todo list. :)
How does pg_autovacuum differ from vacuumdb? I mean it seems to call
the vacuum operation underneath just as vacuumdb does. I obviously
didn't follow the
Manfred Koizar writes:
ISTM you are VACCUMing too aggressively. You are reclaiming less than
1% and 0.005%, respectively, of tuples. I would increase FSM settings
to ca. 1000 fsm_relations, 10 fsm_pages and VACUUM *less* often,
say every two hours or so.
I did this. We'll see how it
Vivek Khera writes:
AMI or Adaptec based?
Adaptec, I think. AIC-7899 LVD SCSI is what dmidecode says, and
Red Hat/Adaptec aacraid driver, Aug 18 2003 is what comes up when it
boots. I haven't be able to use the aac utilities with this driver,
however, so it's hard to interrogate the device.
Tom Lane writes:
... if all tuples are the same size, and if you never have any
Incorrect. If the tuples smaller, Oracle does the right thing. If
there's enough space in the page, it shifts the tuples to make room.
That's what pctfree, pctused and pctincrease allow you to control.
It's all in
Stephen writes:
I ran into the same problem with VACUUM on my Linux box. If you are running
Linux, take a look at elvtune or read this post:
The default values were -r 64 -w 8192. The article said this was
optimal. I just futzed with different values anywere from -w 128 -r
128 to -r 16 -w
Vivek Khera writes:
Also, how close are you to the capacity of your disk bandwidth? I
don't see that in your numbers. I know in freebsd I can run systat
-vmstat and it gives me a percentage of utilization that lets me know
when I'm near the capacity.
The vacuum totally consumes the system.
Greg Stark writes:
I don't understand why you would expect overwriting to win here.
What types of updates do you do on these tables?
These are statistics that we're adjusting. I think that's pretty
normal stuff. The DSS component is the avg() of these numbers on
particular groups. The
Greg Stark writes:
SELECT a, (SELECT name FROM t2 WHERE t2.f2 = t1.f2)
FROM t1
GROUP BY f2
This doesn't solve the problem. It's the GROUP BY that is doing the
wrong thing. It's grouping, then aggregating.
But at least in the form above it will consider using an index on
Josh Berkus writes:
I hope that you'll stay current with PostgreSQL developments so that you can
do a similarly thourough evaluation for your next project.
Oh, no worries. This project just happens to be a tough one. We're
heavily invested in Postgres. Other projects we maintain that use
scott.marlowe writes:
t2 was 'vacuum full'ed and analyzed, right? Just guessing.
Fresh import. I've been told this includes a ANALYZE.
Rob
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
14 matches
Mail list logo
