On Wed, 21 Feb 2007 21:58:33 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> SELECT 'vacuum verbose analyze
> '||quote_ident(nspname)||'.'||quote_ident(relname)||';'
> FROM pg_class c, pg_namespace n
> WHERE relkind = 'r'
> AND relnamespace = n.oid
> AND nspname = 'novac'
> ORD
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
A minor correction to my earlier post: I should have specified the
schema as well in the vacuum command for tables with the same
name in different schemas:
SET search_path = 'pg_catalog';
SELECT set_config('search_path',
current_setting('se
Thank you all for your ideas. I appreciate the quick response.
-Dan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Jacek Zarêba wrote:
Hello, I've set up 2 identical machines, hp server 1ghz p3,
768mb ram, 18gb scsi3 drive. On the first one I've installed
Debian/GNU 4.0 Linux, on the second FreeBSD 6.2. On both
machines I've installed Postgresql 8.2.3 from sources.
Now the point :)) According to my tests post
Mark Stosberg wrote:
> Alvaro Herrera wrote:
> > Mark Stosberg wrote:
> >> When I upgraded a busy database system to PostgreSQL 8.1, I was excited
> >> about AutoVacuum, and promptly enabled it, and turned off the daily
> >> vacuum process.
> >>
> >> (
> >> I set the following, as well as the optio
Mark Stosberg wrote:
Let me ask the question a different way: Is simply setting the two
values plus enabling autovacuuming generally enough, or is further
tweaking common place?
No, most people in addition to setting those two GUC settings also lower
the threshold values (there is a fair amoun
Alvaro Herrera wrote:
> Mark Stosberg wrote:
>> When I upgraded a busy database system to PostgreSQL 8.1, I was excited
>> about AutoVacuum, and promptly enabled it, and turned off the daily
>> vacuum process.
>>
>> (
>> I set the following, as well as the option to enable auto vacuuming
>> stats_s
Hi Dan,
you may take a look at the crosstab contrib module. There you can find
a
function that can convert your rows into columns. However, you can also use
the manual approach, as crosstab has its limitations too.
You can create a TYPE that has all the columns you need, you cre
On 2/21/07, Dan Harris <[EMAIL PROTECTED]> wrote:
I have a new task of automating the export of a very complex Crystal
Report. One thing I have learned in the last 36 hours is that the
export process to PDF is really, really, slooww..
Anyway, that is none of your concern. But, I am thinking th
Le mercredi 21 février 2007 10:57, Jacek Zaręba a écrit :
> Now the point :)) According to my tests postgres on Linux
> box run much faster then on FreeBSD, here are my results:
You may want to compare some specific benchmark, as in bench with you
application queries. For this, you can consider T
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Take a really different approach. Log in CSV format to text files
> instead, And only import the date ranges we need "on demand" if a report
> is requested on the data.
Seems like more work than a separate database to me. :)
> 2. We could fi
Mark Stosberg wrote:
>
> When I upgraded a busy database system to PostgreSQL 8.1, I was excited
> about AutoVacuum, and promptly enabled it, and turned off the daily
> vacuum process.
>
> (
> I set the following, as well as the option to enable auto vacuuming
> stats_start_collector = true
> sta
When I upgraded a busy database system to PostgreSQL 8.1, I was excited
about AutoVacuum, and promptly enabled it, and turned off the daily
vacuum process.
(
I set the following, as well as the option to enable auto vacuuming
stats_start_collector = true
stats_row_level = true
)
I could see in t
I have a new task of automating the export of a very complex Crystal
Report. One thing I have learned in the last 36 hours is that the
export process to PDF is really, really, slooww..
Anyway, that is none of your concern. But, I am thinking that I can
somehow utilize some of PG's strengths
Our application has a table that is only logged to, and infrequently
used for reporting. There generally no deletes and updates.
Recently, the shear size (an estimated 36 million rows) caused a serious
problem because it prevented a "vacuum analyze" on the whole database
from finishing in a timely
Ray Stell wrote:
> I'd like to have a toolbox prepared for when performance goes south.
> I'm clueless. Would someone mind providing some detail about how to
> measure these four items Craig listed:
>
> 1. The first thing is to find out which query is taking a lot of time.
>
> 2. A long-running
On Wed, Feb 21, 2007 at 08:09:49AM -0800, Craig A. James wrote:
> I hope I didn't give the impression that these were the only thing to look
> at ... those four items just popped into my head, because they've come up
> repeatedly in this forum. There are surely more things that could be
> suspe
Ray,
I'd like to have a toolbox prepared for when performance goes south.
I'm clueless. Would someone mind providing some detail about how to
measure these four items Craig listed:
I hope I didn't give the impression that these were the only thing to look at
... those four items just popped
I'd like to have a toolbox prepared for when performance goes south.
I'm clueless. Would someone mind providing some detail about how to
measure these four items Craig listed:
1. The first thing is to find out which query is taking a lot of time.
2. A long-running transaction keeps vacuum from
In response to "Jacek Zaręba" <[EMAIL PROTECTED]>:
> Hello, I've set up 2 identical machines, hp server 1ghz p3,
> 768mb ram, 18gb scsi3 drive. On the first one I've installed
> Debian/GNU 4.0 Linux, on the second FreeBSD 6.2. On both
> machines I've installed Postgresql 8.2.3 from sources.
> Now
On 2/21/07, Jacek Zaręba <[EMAIL PROTECTED]> wrote:
Hello, I've set up 2 identical machines, hp server 1ghz p3,
768mb ram, 18gb scsi3 drive. On the first one I've installed
Debian/GNU 4.0 Linux, on the second FreeBSD 6.2. On both
machines I've installed Postgresql 8.2.3 from sources.
Now the poin
Hello, I've set up 2 identical machines, hp server 1ghz p3,
768mb ram, 18gb scsi3 drive. On the first one I've installed
Debian/GNU 4.0 Linux, on the second FreeBSD 6.2. On both
machines I've installed Postgresql 8.2.3 from sources.
Now the point :)) According to my tests postgres on Linux
box run
22 matches
Mail list logo
