I'm investigating a potential IO issue. We're running 7.4 on AIX 5.1.
During periods of high activity (reads, writes, and vacuums), we are
seeing iostat reporting 100% disk usage. I have a feeling that the
iostat numbers are misleading. I can make iostat usage jump from less
than 10% to
Brad Nicholson wrote:
I'm investigating a potential IO issue. We're running 7.4 on AIX
5.1. During periods of high activity (reads, writes, and vacuums), we
are seeing iostat reporting 100% disk usage. I have a feeling that
the iostat numbers are misleading. I can make iostat usage jump
Joshua D. Drake wrote:
Brad Nicholson wrote:
I'm investigating a potential IO issue. We're running 7.4 on AIX
5.1. During periods of high activity (reads, writes, and vacuums),
we are seeing iostat reporting 100% disk usage. I have a feeling
that the iostat numbers are misleading. I can
Brad Nicholson [EMAIL PROTECTED] writes:
I'm investigating a potential IO issue. We're running 7.4 on AIX 5.1.
During periods of high activity (reads, writes, and vacuums), we are
seeing iostat reporting 100% disk usage. I have a feeling that the
iostat numbers are misleading. I can
[EMAIL PROTECTED] (Tom Lane) writes:
Brad Nicholson [EMAIL PROTECTED] writes:
I'm investigating a potential IO issue. We're running 7.4 on AIX 5.1.
During periods of high activity (reads, writes, and vacuums), we are
seeing iostat reporting 100% disk usage. I have a feeling that the
On Tue, Jan 24, 2006 at 02:43:59PM -0500, Chris Browne wrote:
I believe it's 7.4 where the cost-based vacuum parameters entered in,
so that would, in principle, already be an option.
[rummaging around...]
Hmm There was a patch for 7.4, but it's only standard as of
8.0...
And it
Hi,
We are running Postgresql 8.1, and getting dramatically inconsistant results
after running VACUUM ANALYZE. Sometimes after analyzing the database, the
query planner chooses a very efficient plan (15 rows, 4.744 ms), and
sometimes a terrible one (24 rows, 3536.995 ms). Here's the abbreviated
On Tue, 2006-01-24 at 17:15, Daniel Gish wrote:
Hi,
We are running Postgresql 8.1, and getting dramatically inconsistant results
after running VACUUM ANALYZE. Sometimes after analyzing the database, the
query planner chooses a very efficient plan (15 rows, 4.744 ms), and
sometimes a terrible
On Tue, Jan 24, 2006 at 04:15:57PM -0700, Daniel Gish wrote:
We are running Postgresql 8.1, and getting dramatically inconsistant results
after running VACUUM ANALYZE. Sometimes after analyzing the database, the
query planner chooses a very efficient plan (15 rows, 4.744 ms), and
sometimes a
Hi,
Thanks for your response. The actual query is below; the joins are only 4
deep. Adjusting the stats target did help, but not dramatically.
EFFICIENT PLAN:
# explain analyze SELECT ev.eid FROM events ev INNER JOIN (events_join ej
INNER JOIN (groups_join gj INNER JOIN groups g ON gj.gid =
10 matches
Mail list logo
