Hi all,
I've been searching the list for a while but couldn't find any up-to-date information relating to my problem.
We have a production server with postgresql on cygwin that currently deels with about 200 Gigs of data (1 big IDE drive). We plan to move to linux for some reasons I don't have to
On Tue, 2004-07-20 at 01:52, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I've been searching the list for a while but couldn't find any
> up-to-date information relating to my problem.
> We have a production server with postgresql on cygwin that currently
> deels with about 200 Gigs of data (1 big IDE
Thanks a lot Scott.
It seems that we were totally wrong when considering a network storage solution. I've read your techdoc http://techdocs.postgresql.org/guides/DiskTuningGuide and found many interesting remarks.
I think that we will know focus on external Raid systems which seem to be relativi
[EMAIL PROTECTED] wrote:
As we don't plan to have more than 5 connections (I.E process), we
think SATA drives would fit our requirements. Could this be an issue
for an after crash recovery ?
If you can disable the write ATA write cache, then you have safety.
Unfortunately many cards under Linu
I must say that cygwin did well (there exists good software on windows, i've found one)... as a prototype ... when I look at the postgresql poll (http://www.postgresql.org/survey.php?View=1&SurveyID=11), it seems like I'm not alone !!
Actually, the major problem was the limit of the available allo
Sorry for the late reply - I've been away, and I've had problems posting too
:(
Merlin, I'd like to come back with a few more points!
>That's the whole point: memory is a limited resource. If pg is
>crawling, then the problem is simple: you need more memory.
My posting only relates to the scena
On Thu, Jul 15, 2004 at 02:08:54PM +0200, Steinar H. Gunderson wrote:
> sort_mem is already 16384, which I thought would be plenty -- I tried
> increasing it to 65536 which made exactly zero difference. :-)
I've tried some further tweaking, but I'm still unable to force it into doing
a hash join -
...and on Tue, Jul 20, 2004 at 09:52:56AM +0200, [EMAIL PROTECTED] used the keyboard:
> Hi all,
>
> I've been searching the list for a while but couldn't find any up-to-date
> information relating to my problem.
> We have a production server with postgresql on cygwin that currently deels
> with
>
> Oh, and not to forget - the price for a 3ware 9500S-12, the version
> we're testing ranges between EUR1000 and EUR1500, depending on the
> contract you have with the reseller and the intended use of the
> device. SATA disks are dirt-cheap nowadays, as has been mentioned
> before.
>
Correctio
On Tue, 2004-07-20 at 03:32, [EMAIL PROTECTED] wrote:
> Thanks a lot Scott.
>
> It seems that we were totally wrong when considering a network storage
> solution. I've read your techdoc
> http://techdocs.postgresql.org/guides/DiskTuningGuide and found many
> interesting remarks.
> I think that we
[EMAIL PROTECTED] wrote:
Would NAS or SAN be good solutions ? (I've read that NAS uses NFS which
could slow down the transfer rate ??)
Has anyone ever tried one of these with postgresql ?
Not (yet) with Postgres, but my company has run ~100GB Oracle database
on NAS (NetApp) for the past couple
Steinar,
> I've tried some further tweaking, but I'm still unable to force it into
> doing a hash join -- any ideas how I can find out why it chooses a merge
> join?
I'm sorry, I can't really give your issue the attention it deserves. At this
point, I'd have to get a copy of your database, and
Steinar,
> I've tried some further tweaking, but I'm still unable to force it into
> doing a hash join -- any ideas how I can find out why it chooses a merge
> join?
Actually, quick question -- have you tried setting enable_mergjoin=false to
see the plan the system comes up with? Is it in fact
On Tue, Jul 20, 2004 at 10:06:08AM -0700, Josh Berkus wrote:
> Actually, quick question -- have you tried setting enable_mergjoin=false to
> see the plan the system comes up with? Is it in fact faster?
It is significantly faster -- 1200ms vs. 1900ms (on 7.4, at least). Some of
the merge joins ar
> Would NAS or SAN be good solutions ? (I've read that NAS uses NFS
> which could slow down the transfer rate ??)
> Has anyone ever tried one of these with postgresql ?
I've used both a NetApp and Hitachi based SANs with PostgreSQL. Both
work as well as expected, but do require some tweeking as t
I have (among other things) a parent table with 200 records and a child table with
20MM or more. I set up referential integrity on the FK with ON DELETE CASCADE.
It appears that when a DELETE is done on the parent table, the child table deletion is
done with a sequential scan. I say this because
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
> I have (among other things) a parent table with 200 records and a child
> table with 20MM or more. I set up referential integrity on the FK with
> ON DELETE CASCADE.
>
> It appears that when a DELETE is done on the parent table, the child
> table del
On Tue, 20 Jul 2004, Stephan Szabo wrote:
>
> On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
>
> > I have (among other things) a parent table with 200 records and a child
> > table with 20MM or more. I set up referential integrity on the FK with
> > ON DELETE CASCADE.
> >
> > It appears that when a
PREPARE c(int4) AS DELETE FROM childtable WHERE fk=$1;
EXPLAIN EXECUTE c(-1);
gives an index scan.
PREPARE c2(int4) AS DELETE FROM parenttable WHERE key=$1;
EXPLAIN EXECUTE c2(1);
gives a seq scan on the parent table (itself a little curious) and no explanation of
what the triggers are doing.
I FOUND IT!
A second trigger that doesn't belong..
OK, we're set now, and thanks for showing me some ways to check what the planner is up
to. Is there a way of seeing what the triggers will do?
---(end of broadcast)---
TIP 4: Don't 'kill -9' t
I have (among other things) a parent table with 200 records and a child table with
20MM or more. I set up referential integrity on the FK with ON DELETE CASCADE.
It appears that when a DELETE is done on the parent table, the child table deletion is done with a sequential scan. I say this because i
> I could of course post the updated query plan if anybody is interested; let
> me know. (The data is still available if anybody needs it as well, of
> course.)
I've taken a look and managed to cut out quite a bit of used time.
You'll need to confirm it's the same results though (I didn't -- it is
22 matches
Mail list logo
