Hello,
I have the following problem:
When I run some query after I just run the Postmaster, it takse
several seconds to execute (sometimes more than 10), if I rerun it
again afterwards, it takes mere milliseconds.
So, I guess it has to do with PostgreSQL caching.. But how exactly
does it work?
while you weren't looking, Vitaly Belman wrote:
So, I guess it has to do with PostgreSQL caching.. But how exactly
does it work? What does it cache? And how can I control it?
PostgreSQL uses the operating system's disk cache. You can hint to
the postmaster how much memory is available for
Vitaly Belman wrote:
Hello,
I have the following problem:
When I run some query after I just run the Postmaster, it takse
several seconds to execute (sometimes more than 10), if I rerun it
again afterwards, it takes mere milliseconds.
So, I guess it has to do with PostgreSQL caching.. But how
[EMAIL PROTECTED] (Richard Huxton) writes:
If you could pin data in the cache it would run quicker, but at the
cost of everything else running slower.
Suggested steps:
1. Read the configuration/tuning guide at:
http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php
2. Post a sample
What is essentially required is the prescient cacheing algorithm,
where the postmaster must consult /dev/esp in order to get a
prediction of what blocks it may need to refer to in the next sixty
seconds.
Easy enough. Television does it all the time with live shows. The guy
with the buzzer
All,
I have a particularly troublesome table in my 7.3.4 database. It
typically has less than 50k rows, and a usage pattern of about 1k
INSERTs, 50-100k UPDATEs, and no DELETEs per day. It is vacuumed and
analyzed three times per week. However, the performance of queries
performed on this
Rosser Schwarz wrote:
PostgreSQL uses the operating system's disk cache.
... in addition to its own buffer cache, which is stored in shared
memory. You're correct though, in that the best practice is to keep the
PostgreSQL cache small and give more memory to the operating system's
disk cache.
Is there any way to avoid doing a periodic VACUUM FULL on this table,
given the fairly radical usage pattern? Or is the (ugly) answer to
redesign our application to avoid this usage pattern?
Yes, you should be able to doing avoid periodic VACUUM FULL. The problem
is that your table needs to
Not knowing a whole lot about the internals of Pg, one thing jumped out
at me, that each trip to get data from bv_books took 2.137 ms, which
came to over 4.2 seconds right there.
The problem seems to be the 1993 times that the nested loop spins, as
almost all of the time is spent there.
BM == Bill Montgomery [EMAIL PROTECTED] writes:
BM Is there any way to avoid doing a periodic VACUUM FULL on this table,
BM given the fairly radical usage pattern? Or is the (ugly) answer to
BM redesign our application to avoid this usage pattern?
I'll bet upgrading to 7.4.2 clears up your
Matthew T. O'Connor wrote:
Is there any way to avoid doing a periodic VACUUM FULL on this table,
given the fairly radical usage pattern? Or is the (ugly) answer to
redesign our application to avoid this usage pattern?
pg_autovacuum would probably help as it monitors activity and vacuumus
Bill Montgomery [EMAIL PROTECTED] writes:
I have a particularly troublesome table in my 7.3.4 database. It
typically has less than 50k rows, and a usage pattern of about 1k
INSERTs, 50-100k UPDATEs, and no DELETEs per day. It is vacuumed and
analyzed three times per week.
You probably want
I will soon have at my disposal a new IBM pSeries server. The main
mission for this box will be to serve several pg databases. I have
ordered 8GB of RAM and want to learn the best way to tune pg and AIX for
this configuration. Specifically, I am curious about shared memory
limitations.
Clinging to sanity, [EMAIL PROTECTED] (Dan Harris) mumbled into her beard:
I will soon have at my disposal a new IBM pSeries server. The main
mission for this box will be to serve several pg databases. I have
ordered 8GB of RAM and want to learn the best way to tune pg and AIX
for this
Christopher Browne wrote:
One of our sysadmins did all the configuring OS stuff part; I don't
recall offhand if there was a need to twiddle something in order to
get it to have great gobs of shared memory.
FWIW, the section on configuring kernel resources under various
Unixen[1] doesn't have any
15 matches
Mail list logo
