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 bel
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=149349&cid=12519114
> >
>
> Well, that's old enough
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 i
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
-
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 (pgsql-p
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 you
Rainer Pruy 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 to do to avoid giv
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 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
> ;
>
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]
S
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 = h.ContextIdx
storing all fields as varchar surely doesn't make:
- indicies small,
- the thing fly,
- tables small.
...
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 25
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.
14 matches
Mail list logo
