On Thu, 19 Apr 2007, Sergey Tsukinovsky wrote:
I know that 7.0.2 is an old version and therefore ran the same test on
7.3.18 - the performance behavior was similar.
Why have you choosen just another very old version for performance
comparison and not the latest stable release?
Kind regards
On Tue, Apr 17, 2007 at 04:13:36PM -0500, David Hinkle wrote:
I have a table where I store email, the bodies are mostly kept in a
toast table.The toast table is 940 Meg in size. The whole database
is about 1.2 Gig in size. When I back the database up using pg_dump in
custom output
Am Donnerstag, 19. April 2007 schrieb Sergey Tsukinovsky:
2. What would be the recommended set of parameters to tune up in order
to improve the performance over the time, instead of considering an
option to vacuum every 30 minutes or so?
3. Is it safe to run 'vacuum' as frequently as every
Nelson Kotowski wrote:
So far, i need to do it in three different scale factors (1, 2 and 5GB
databases).
My build process comprehends creating the tables without any foreign keys,
indexes, etc. - Running OK!
Then, i load the data from the flat files generated through DBGEN software
into these
Well, that's darn odd. It should not be getting that so far wrong.
What's the datatype of the status column exactly (I'm guessing varchar
but maybe not)? Would you show us the pg_stats row for the status column?
It has been created as a char(1) in fact. The pg_stats row for the status
column
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeroen Kleijer
The problems comes when I try to do a query without using a
where clause
because by then, it completely discards the indexes and does
a complete
table scan which takes over half an hour! (40.710.725 rows,
At 04:53 AM 4/23/2007, Mario Weilguni wrote:
Am Donnerstag, 19. April 2007 schrieb Sergey Tsukinovsky:
2. What would be the recommended set of parameters to tune up in order
to improve the performance over the time, instead of considering an
option to vacuum every 30 minutes or so?
3. Is it
Hi Heikki,
Thanks for answering! :)
I don't get how creating only the indexes i cluster on would improve my
cluster command perfomance. I believed that all other indexes wouldn't
interfere because so far they're created in a fashionable time and they
don't refer to any field/column in the
On Thu, 2007-04-19 at 14:29, Sergey Tsukinovsky wrote:
Hi,
I’m currently dealing with performance issues of postgres and looking
for some advice.
Platform
Postgres: 7.0.2
OS: FreeBSD4.4
DB: size - about 50M, most frequently updated tables are of an average
size of
Hi,
I have a table in my database that is updated every minute with new acquired
data. Anyway there is a query to get latest values to be displayed on
screen. I have postgresql 7.4.2 that work very fine. The problem was that
after hdd crash I have rebuild database from the archive and...
On Mon, Apr 23, 2007 at 07:20:29PM +0200, Arkadiusz Raj wrote:
I have a table in my database that is updated every minute with new acquired
data. Anyway there is a query to get latest values to be displayed on
screen. I have postgresql 7.4.2 that work very fine.
You want _at least_ the
On Mon, Apr 23, 2007 at 10:52 AM, in message
[EMAIL PROTECTED], Nelson
Kotowski [EMAIL PROTECTED] wrote:
I don't get how creating only the indexes i cluster on would improve my
cluster command perfomance. I believed that all other indexes wouldn't
interfere because so far they're created
On Apr 23, 2007, at 12:09 PM, Scott Marlowe wrote:
And do you have 32 or 64 Megs of memory in that machine?
Cause honestly, that's the kinda hardware I was running 7.0.2 on,
so you
might as well get retro in your hardware department while you're at
it.
I think you're being too
On Mon, 2007-04-23 at 15:00, Vivek Khera wrote:
On Apr 23, 2007, at 12:09 PM, Scott Marlowe wrote:
And do you have 32 or 64 Megs of memory in that machine?
Cause honestly, that's the kinda hardware I was running 7.0.2 on,
so you
might as well get retro in your hardware department
Scott Marlowe wrote:
(snippage) that's the kinda hardware I was running 7.0.2 on, so you
might as well get retro in your hardware department while you're at it.
Notice he's running FreeBSD 4.4(!), so it could well be a very old
machine...
Cheers
Mark
---(end of
On Sat, 21 Apr 2007, Nelson Kotowski wrote:
I identified that the cluster command over the lineitem table (cluster
idx_lineitem on lineitem) is the responsible. I got to this conclusion
because when i run it in the 1GB and 2GB database i am able to complete
this script in 10 and 30 minutes
On Mon, 23 Apr 2007, Scott Marlowe wrote:
I honestly kinda wondered if the original post came out of a time warp,
like some mail relay somewhere held onto it for 4 years or something.
That wouldn't be out of the question if this system is also his mail
server.
--
* Greg Smith [EMAIL
17 matches
Mail list logo
