Joe wrote:
I have a very busy system that takes about 9 million inserts per day and each
record gets
updated at least once after the insert (all for the one same table), there
are other tables that
get hit but not as severely. As suspected I am having a problem with table
bloat. Any
Sorry, additional info:
OS is Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
DISK - IBM DS4700 Array - 31 drives and 1 hot spare - RAID10 - 32MB stripe
Sysctl.conf
kernel.shmmax=6442450944
kernel.shmall=1887436
kernel.msgmni=1024
kernel.msgmnb=65536
kernel.msgmax=65536
kernel.sem=250
storing all fields as varchar surely doesn't make:
- indicies small,
- the thing fly,
- tables small.
...
Hi all,
I'm quite puzzled by the following observation.
The behaviour is observed on a production system (Linux, PG 8.3.5)
and also on a test system (NetBSD 5.0.2, PG 8.4.2).
Normally the following Query behaves well:
select c.*, h.*
from Context c, Context_Hierarchy h
where c.Idx =
Sorry, this is a “black box” application, I am bound by what they give me as
far as table layout, but I fully understand the rationale. I believe this
application spent its beginnings with Oracle, which explains the blanket use of
VARCHAR.
From: Grzegorz Jaśkiewicz [mailto:gryz...@gmail.com]
Rainer Pruy rainer.p...@acrys.com writes:
Normally the following Query behaves well:
select c.*, h.*
from Context c, Context_Hierarchy h
where c.Idx = h.ContextIdx and c.ContextId='testID' and
h.HierarchyName='InsuranceHierarchy' and h.ParentIdx=49292395
;
Thanks for the hint.
I should have been considering that in the first place.
(But the obvious is easily left unrecognised..)
The prepared statement gives:
QUERY
PLAN
Rainer Pruy rainer.p...@acrys.com writes:
The prepared statement gives:
...
And that is quite a bad plan given the current distribution of values.
Yeah. The planner really needs to know the actual parameter values in
order to pick the best plan for this case.
One thing that you might be able
I'm already at it
It is a Java app, using jdbc, but through a proprietary persistence framework.
I'm just busy evaluating the effects on the app of prohibiting prepared
statements via jdbc.
If this is not worthwhile, I'm bound to some expensive reorganizations, sigh.
Nevertheless,
thanks for
When I use intervals in my query e.g col1 between current_timestamp -
interval '10 days' and current_timestamp...the optimizer checks ALL
partitions whereas if I use col1 between 2 hardcoded dates..only
the applicable partitions are scanned.
--
Sent via pgsql-performance mailing list
Rainer Pruy wrote:
Thanks for the hint.
I should have been considering that in the first place.
(But the obvious is easily left unrecognised..)
The prepared statement gives:
QUERY
PLAN
Ron Mayer wrote:
Bruce Momjian wrote:
Greg Smith wrote:
Bruce Momjian wrote:
I have added documentation about the ATAPI drive flush command, and the
If one of us goes back into that section one day to edit again it might
be worth mentioning that FLUSH CACHE EXT is the actual
Greg Smith wrote:
Ron Mayer wrote:
Linux apparently sends FLUSH_CACHE commands to IDE drives in the
exact sample places it sends SYNCHRONIZE CACHE commands to SCSI
drives[2].
[2] http://hardware.slashdot.org/comments.pl?sid=149349cid=12519114
Well, that's old enough to not even
Bruce Momjian wrote:
I always assumed SCSI disks had a write-through cache and therefore
didn't need a drive cache flush comment.
There's more detail on all this mess at
http://wiki.postgresql.org/wiki/SCSI_vs._IDE/SATA_Disks and it includes
this perception, which I've recently come to
14 matches
Mail list logo
