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 PROTECT
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 eac
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 b
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 de
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 conservati
>>> 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'
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 lat
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... Execution
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
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 orders
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. I
> 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
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
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 t
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 ever
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
16 matches
Mail list logo
