Luiz K. Matsumura luiz 'at' planit.com.br writes:
If we run the commands vacumm full analyze
If you're using the cost based vacuum delay, don't forget that it
will probably take long; possibly, you may deactivate it locally
before running VACUUM FULL, in case the locked table is mandatory
for
On Jan 23, 2008 3:02 AM, Guillaume Smet [EMAIL PROTECTED] wrote:
I'll post my results tomorrow morning.
It works perfectly well:
cityvox_prod=# CREATE OR REPLACE FUNCTION
getTypesLieuFromTheme(codeTheme text) returns text[] AS
$f$
SELECT ARRAY(SELECT codetylieu::text FROM rubtylieu WHERE codeth
Hi Tom,
On May 9, 2007 6:40 PM, Tom Lane [EMAIL PROTECTED] wrote:
To return to your original comment: if you're trying to model a
situation with a fully cached database, I think it's sensible
to set random_page_cost = seq_page_cost = 0.1 or so.
Is it still valid for 8.3 or is there any reason
I've got two huge tables with one-to-many relationship with complex
key. There's also a view, which JOINs the tables, and planner chooses
unoptimal plan on SELECTs from this view.
The db schema is declared as: (from on now, I skip the unsignificant
columns for the sake of simplicity)
CREATE
In response to Joshua Fielek [EMAIL PROTECTED]:
Hey folks --
For starters, I am fairly new to database tuning and I'm still learning
the ropes. I understand the concepts but I'm still learning the real
world impact of some of the configuration options for postgres.
We have an
Guillaume Smet [EMAIL PROTECTED] writes:
It doesn't look like an EXPLAIN ANALYZE output. Can you provide a real
one (you should have a second set of numbers with EXPLAIN ANALYZE)?
Also, could we see the pg_stats rows for the columns being joined?
regards, tom lane
I'm not sure what is going on but looking for some advice, knowledge.
I'm running multiple postgres servers in a slon relationship. I have
hundreds of thousands of updates, inserts a day. But what I'm seeing
is my server appears to deallocate memory (for the lack of a better
term) and performance
On Jan 23, 2008 8:01 AM, mike long [EMAIL PROTECTED] wrote:
Scott,
What are your thoughts on using one of those big RAM appliances for
storing a Postgres database?
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your
hi
We have an installation of Postgres 8.1.2 (32bit on Solaris 9) with a DB
size of about 250GB on disk. The DB is subject to fair amount of
inserts, deletes and updates per day.
Running VACUUM VERBOSE tells me that I should allocate around 20M pages
to FSM (max_fsm_pages)! This looks like a
Josh what about the rest of your system? What operating system? Your
hardware setup. Drives? Raids? What indices do you have setup for
these queries? There are other reasons that could cause bad queries
performance.
On Jan 22, 2008 11:11 PM, Joshua Fielek [EMAIL PROTECTED] wrote:
Hey folks
On Jan 23, 2008, at 1:29 PM, Thomas Lozza wrote:
We have an installation of Postgres 8.1.2 (32bit on Solaris 9) with
a DB
size of about 250GB on disk. The DB is subject to fair amount of
inserts, deletes and updates per day.
Running VACUUM VERBOSE tells me that I should allocate around 20M
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional work) the SSD can be
Vivek Khera [EMAIL PROTECTED] writes:
On Jan 23, 2008, at 1:29 PM, Thomas Lozza wrote:
We have an installation of Postgres 8.1.2 (32bit on Solaris 9) with
...
it sounds to me like your autovacuum is not running frequently enough.
Yeah. The default autovac settings in 8.1 are extremely
Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional
On Jan 23, 2008, at 2:57 PM, Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server
will
be a better way to spend your money. For certain high throughput,
relatively
Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional
On Wed, 23 Jan 2008, Tory M Blue wrote:
I have hundreds of thousands of updates, inserts a day. But what I'm
seeing is my server appears to deallocate memory (for the lack of a
better term) and performance goes to heck, slow response, a sub second
query takes anywhere from 6-40 seconds to
On Wed, 23 Jan 2008, Guy Rouillier wrote:
Flash has a limited number of writes before it becomes unreliable. On
good quality consumer grade, that's about 300,000 writes, while on
industrial grade it's about 10 times that.
The main advance that's made SSD practical given the write cycle
On Jan 23, 2008 1:57 PM, Guy Rouillier [EMAIL PROTECTED] wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
19 matches
Mail list logo
