[snip]
> Yes, but it could be a disk issue because you're doing more work than
> you need to. If your UPDATEs are chasing down a lot of dead tuples,
> for instance, you'll peg your I/O even though you ought to have I/O
> to burn.
OK, this sounds interesting, but I don't understand: why would an u
Title: Optimizer misconfigured ?
Hello,
I have a strange effect on upcoming structure :
DEX_OBJ ---< DEX_STRUCT >--- DEX_LIT
DEX_OBJ : 100 records (#DOO_ID, DOO_NAME)
DEX_STRUCT : 2,5 million records (#(DST_SEQ, FK_DOO_ID, FK_LIT_ID))
DEX_LIT : 150K records (#LIT_ID, LIT_TEXT)
[EMAIL PROTECTED] wrote:
>>> Have you tried reindexing your active tables?
> It will cause some performance hit while you are doing it. It
> sounds like something is bloating rapidly on your system and
> the indexes is one possible place that could be happening.
You might consider using contrib/
[EMAIL PROTECTED] wrote:
> Next we'll upgrade the postgres hardware, and then I'll come
> back to report if it's working better... sorry for the noise for now.
There have been some discussions about which hardware suits PostgreSQL's
needs best under certain load-characteristics. We have experienc
Nörder-Tuitje wrote:
Hello,
I have a strange effect on upcoming structure :
People will be wanting the output of EXPLAIN ANALYSE on that query.
They'll also ask whether you've VACUUMed, ANALYSEd and configured your
postgresql.conf correctly.
--
Richard Huxton
Archonet Ltd
---
On Thu, Oct 13, 2005 at 10:15:03AM +0200, Csaba Nagy wrote:
>
> OK, this sounds interesting, but I don't understand: why would an update
> "chase down a lot of dead tuples" ? Should I read up on some docs, cause
> I obviously don't know enough about how updates work on postgres...
Right. Here's
Thanks Andrew, this explanation about the dead rows was enlightening.
Might be the reason for the slowdown I see on occasions, but not for the
case which I was first observing. In that case the updated rows are
different for each update. It is possible that each row has a few dead
versions, but not
On 10/13/05, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-10-13 at 14:40, Andrew Sullivan wrote:
> > On Thu, Oct 13, 2005 at 10:15:03AM +0200, Csaba Nagy wrote:
> > > And how would the analyze help in finding this out ? I thought it would
> > > only show me additionally the actual timings,
On Mon, Oct 10, 2005 at 05:31:10PM +0300, Andy wrote:
> I read some tuning things, I made the things that are written there, but I
> think that there improvements can be made.
Have you tried the suggestions people made? Because if I were you,
I'd be listing very carefully to what Chris and Tom w
On Thu, Oct 13, 2005 at 03:14:44PM +0200, Csaba Nagy wrote:
> In any case, I suppose that those disk pages should be in OS cache
> pretty soon and stay there, so I still don't understand why the disk
> usage is 100% in this case (with very low CPU activity, the CPUs are
> mostly waiting/idle)... th
Pg 7.4.5
RH 7.3
Quad Xeon 3Gz
12G ram
Trying to do a update of fields on 23M row database.
Is it normal for this process to take 16hrs and still clocking? Both join
fields are indexed and I have removed any indexes on the updated columns.
Also both tables are vacuumed regularly.
I'm weary to can
Patrick Hatcher <[EMAIL PROTECTED]> writes:
> Pg 7.4.5
> Trying to do a update of fields on 23M row database.
> Is it normal for this process to take 16hrs and still clocking?
Are there foreign keys pointing at the table being updated? If so,
failure to index the referencing columns could create
Thanks. No foreign keys and I've been bitten by the mismatch datatypes and
checked that before sending out the message :)
Patrick Hatcher
Development Manager Analytics/MIO
Macys.com
Tom Lane
13 matches
Mail list logo
