Tom,
On Nov 8, 2007 12:14 AM, Tom Lane [EMAIL PROTECTED] wrote:
I've applied a patch that might help you:
http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
AFAICS, it doesn't seem to fix the problem. I just compiled
REL8_1_STABLE branch and I still has the following
Rafael Martinez wrote:
This is a question about something we have seen sometimes in the last
months. It happens with tables with a large amount of updates/selects
compared with the amount of inserts/deletes. The sizes of these tables
are small and the amount of rows too.
The 'problem' is that
Performance problems with heavily modified tables (UPDATE or DELETE) are
usually caused by not vacuuming. There are two main modes the VACUUM can
run in (plain or full) and the former works in a much more aggressive
way (exclusive locking, etc). Try to run VACUUM FULL VERBOSE on the
table and
Hello
This is a question about something we have seen sometimes in the last
months. It happens with tables with a large amount of updates/selects
compared with the amount of inserts/deletes. The sizes of these tables
are small and the amount of rows too.
The 'problem' is that performance
Rafael Martinez wrote:
Hello
This is a question about something we have seen sometimes in the last
months. It happens with tables with a large amount of updates/selects
compared with the amount of inserts/deletes. The sizes of these tables
are small and the amount of rows too.
The
Guillaume Smet [EMAIL PROTECTED] writes:
On Nov 8, 2007 12:14 AM, Tom Lane [EMAIL PROTECTED] wrote:
I've applied a patch that might help you:
http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
AFAICS, it doesn't seem to fix the problem.
Hmm, can we see the pg_stats row for
Heikki Linnakangas wrote:
Rafael Martinez wrote:
The tables with this 'problem' are not big, so CLUSTER finnish very fast
and it does not have an impact in the access because of locking. But we
wonder why this happens.
2 seconds for seq scanning 12 MB worth of data sounds like a lot. Have
Heikki Linnakangas wrote:
If the table is already bloated, a VACUUM won't usually shrink it. It
only makes the space available for reuse, but a sequential scan still
needs to go through a lot of pages.
CLUSTER on the other hand repacks the tuples and gets rid of all the
unused space on
In response to Rafael Martinez [EMAIL PROTECTED]:
Heikki Linnakangas wrote:
Rafael Martinez wrote:
The tables with this 'problem' are not big, so CLUSTER finnish very fast
and it does not have an impact in the access because of locking. But we
wonder why this happens.
2 seconds
Rafael Martinez wrote:
Heikki Linnakangas wrote:
On a small table like that you could run VACUUM every few minutes
without much impact on performance. That should keep the table size in
check.
Ok, we run VACUUM ANALYZE only one time a day, every night. But we would
espect the performance to
Alvaro Herrera wrote:
Rafael Martinez wrote:
The 'problem' is that performance decrease during the day and the only
thing that helps is to run CLUSTER on the table with problems. VACUUM
ANALYZE does not help.
Probably because all the live tuples are clustered at the end of the
table, and
On Nov 6, 2007, at 1:10 PM, Greg Smith wrote:
elsewhere. But once you have enough disks in an array to spread all
the load over that itself may improve write throughput enough to
still be a net improvement.
This has been my expeience with 14+ disks in an array (both RAID10 and
RAID5).
Guillaume Smet [EMAIL PROTECTED] writes:
On Nov 8, 2007 12:14 AM, Tom Lane [EMAIL PROTECTED] wrote:
I've applied a patch that might help you:
http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
AFAICS, it doesn't seem to fix the problem. I just compiled
REL8_1_STABLE branch
[EMAIL PROTECTED] (Rafael Martinez) writes:
Heikki Linnakangas wrote:
On a small table like that you could run VACUUM every few minutes
without much impact on performance. That should keep the table size in
check.
Ok, we run VACUUM ANALYZE only one time a day, every night. But we would
On Nov 6, 2007, at 5:12 AM, Tore Halset wrote:
Here are our current alternatives:
Two things I recommend. If the drives are made by western digital,
run away.
If the PERC5/i is an Adaptec card, run away.
Max out your cache RAM on the RAID card. 256 is the minimum when you
have such
Rafael Martinez [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
On a small table like that you could run VACUUM every few minutes
without much impact on performance. That should keep the table size in
check.
Ok, we run VACUUM ANALYZE only one time a day, every night.
There's your
On Nov 8, 2007 4:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Hmm, can we see the pg_stats row for the ancestors column?
Sure:
public | cms_items | ancestors | 0 |32 |
-1 | | |
On Nov 8, 2007 10:43 AM, Vivek Khera [EMAIL PROTECTED] wrote:
On Nov 6, 2007, at 1:10 PM, Greg Smith wrote:
elsewhere. But once you have enough disks in an array to spread all
the load over that itself may improve write throughput enough to
still be a net improvement.
This has been my
On Nov 5, 2007, at 8:19 AM, Claus Guttesen wrote:
I will get four 72 GB sas-disks at 15K rpm. Reading the archives
suggest raid 1+0 for optimal read/write performance, but with a solid
raid-controller raid 5 will also perform very well when reading.
If you only have 4 drives, I'd recommend
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote:
I am having an issue on PostgreSQL 8.0.12. In the past we had performance
issues with the query planner for queries on some tables where we knew we
had indexes and it was doing a
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote:
I am having an issue on PostgreSQL 8.0.12. In the past we had performance
issues with the query planner for queries on some tables where we knew we
had indexes and it was doing a
On Nov 8, 2007 2:56 PM, Alan Hodgson [EMAIL PROTECTED] wrote:
On Thursday 08 November 2007, Dimitri Fontaine [EMAIL PROTECTED]
Is raid6 better than raid10 in term of overall performances, or a better
cut when you need capacity more than throughput?
You can't touch RAID 10 for performance or
On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote:
I am having an issue on PostgreSQL 8.0.12. In the past we had performance
issues with the query planner for queries on some tables where we knew we
had indexes and it was doing a sequential scan, and for this reason we
issue SET
Ooops, sorry about the multiple copies there --- not sure what happened.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Hello,
I am having an issue on PostgreSQL 8.0.12. In the past we had
performance issues with the query planner for queries on some tables
where we knew we had indexes and it was doing a sequential scan, and
for this reason we issue SET enable_seqscan = FALSE for some queries.
Recently we
On Thursday 08 November 2007, Dimitri Fontaine [EMAIL PROTECTED]
Is raid6 better than raid10 in term of overall performances, or a better
cut when you need capacity more than throughput?
You can't touch RAID 10 for performance or reliability. The only reason to
use RAID 5 or RAID 6 is to get
On Thu, Nov 8, 2007 at 2:14 PM, in message
[EMAIL PROTECTED], Dimitri Fontaine
[EMAIL PROTECTED] wrote:
The Dell 2900 5U machine has 10 spindles max, that would make 2 for the OS
(raid1) and 8 for mixing WAL and data... not enough to benefit from the
move,
or still to test?
From our
Le Thursday 08 November 2007 19:22:48 Scott Marlowe, vous avez écrit :
On Nov 8, 2007 10:43 AM, Vivek Khera [EMAIL PROTECTED] wrote:
On Nov 6, 2007, at 1:10 PM, Greg Smith wrote:
elsewhere. But once you have enough disks in an array to spread all
the load over that itself may improve
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote:
I am having an issue on PostgreSQL 8.0.12. In the past we had performance
issues with the query planner for queries on some tables where we knew we
had indexes and it was doing a
On Nov 8, 2007, at 1:22 PM, Scott Marlowe wrote:
I've heard the newest adaptecs, even the perc implementations aren't
bad.
I have a pair of Adaptec 2230SLP cards. Worst. Just replaced them on
Tuesday with fibre channel cards connected to external RAID
enclosures. Much nicer.
Gregory Stark [EMAIL PROTECTED] writes:
Doesn't really strike at the core reason that this is so klugy though. Surely
the right thing is to push the concept of open versus closed end-points
through deeper into the estimation logic?
No, the right thing is to take the folk who defined dictionary
Tom Lane [EMAIL PROTECTED] writes:
What I am tempted to do about this is have make_greater_string tack zz
onto the supplied prefix, so that it would have to find a string that
compares greater than 123/zz before reporting success. This is
getting pretty klugy though, so cc'ing to
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote:
I am having an issue on PostgreSQL 8.0.12. In the past we had performance
issues with the query planner for queries on some tables where we knew we
had indexes and it was doing a
I wrote:
I did do some experimentation and found that among the ASCII characters
(ie, codes 32-126), nearly all the non-C locales on my Fedora machine
sort Z last and z next-to-last or vice versa. Most of the remainder
sort digits last and z or Z as the last non-digit character. Since Z is
Larry,
Considering these recommendations, let's try setting shared_buffers to 2GB
and work_mem to 16MB. The thing is that work_mem is per connection, and if
we get too aggressive and we get a lot of simultaneous users, we can
potentially eat up a lot of memory.
So 2GB + (100 * 16MB) =
On Wednesday 31 October 2007 12:45, Ketema wrote:
I am trying to build a very Robust DB server that will support 1000+
concurrent users (all ready have seen max of 237 no pooling being
used). I have read so many articles now that I am just saturated. I
have a general idea but would like
I have a database where I dropped all indexes on a table last night
and built a new set of indexes. The goal is to try and let the
database have fewer indexes and use them more. I removed a bunch of
indexes that were surviving from our 7.3 days where functionality will
now be covered by 8.1's
Chris Hoover [EMAIL PROTECTED] writes:
If there has been no scans on an index (as according to
pg_stat_user_indexes), why is pg_statio_user_indexes showing non 0
values in idx_blks_hit/read?
I grow weary, but I think that scan is only incremented by commencing
a SELECT search using the index,
On Nov 9, 2007 3:08 AM, Tom Lane [EMAIL PROTECTED] wrote:
This rule works for all the locales I have installed ... but I don't
have any Far Eastern locales installed. Also, my test cases are only
covering ASCII characters, and I believe many locales have some non-ASCII
letters that sort after
39 matches
Mail list logo
