Re: [GENERAL] Performance of Postgres via network connections
> Since most RAID servers can't even flood a 100 mbit connection, you're more > than safe with that much bandwidth if most of your traffic is going to be > database related. You might want to factor in all the other network > traffic that will be going over those lines though. For instance, if the > app servers are going to be mounting partitions off of a RAID server on the > same network, and your Internet connection comes in there too, you might > start to run into problems. The database shouldn't even come close though. Thank you, I appreciate the comments. Each app server is actually going to have two 100 mbit cards, one to connect it to the RAID array, and one to connect it to the database machine. Your comments give me even more hope that this will work as well as we hope. ; ) After this is all set up, if anyone would like, I may type up an explanation of how things were done as well as costs, for those going through the same sort of growing pains. It's certainly been a lot of work for us to hammer out all of the details, hopefully that would help someone else avoid the work. steve
Re: [GENERAL] Trigger programming..
"Mitch Vincent" <[EMAIL PROTECTED]> writes: > I have this code... > tupdesc = rel->rd_att; /* what the tuple looks like (?) */ > app_id_colnum = SPI_fnumber(tupdesc, app_id_fieldname); > if (app_id_colnum == SPI_ERROR_NOATTRIBUTE) >elog(ERROR, "app_id_colnum - SPI_ERROR_NOATTRIBUTE error "); > char_app_id = SPI_getvalue(rettuple, tupdesc, app_id_colnum); Looks OK to me, as far as it goes. I'd wonder whether the tuple actually matches the tupdesc you're using. Looking at SPI_getvalue itself (in src/backend/executor/spi.c), I can see that SPI_result might offer a clue about why it's failing. regards, tom lane
Re: [GENERAL] pg_dumpall and check constraints
At 17:56 30/06/00 +0200, Jan Wieck wrote: > >For gods sake they don't have. And I'm uncertain that it >should ever work. Sorry...I'm the one to blame for the suggestion. My only defense is it was late, and I was misled by the parser...never the less... >How should a RESTRICT or ON >DELETE CASCADE work in that scenario? Perhaps as Check constraints on all tables in the view...for the most part I would not expect complex views to be used in this way, but since this is what the user would have to do anyway, why not do it for them? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.C.N. 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [GENERAL] pg_dumpall and check constraints
> >How should a RESTRICT or ON > >DELETE CASCADE work in that scenario? > > Perhaps as Check constraints on all tables in the view...for the most part > I would not expect complex views to be used in this way, but since this is > what the user would have to do anyway, why not do it for them? I'd say that for right now, way to complicated... Any non-trivial view would be an incredible pain. Although, once we properly insist on there being a unique constraint on the columns referenced, it would probably be easier (although can you actually put a unique constraint on a view?) Take, for example, create view x as select a.id, c.name from a,b,c where a.id=b.id and a.type=c.type and b.customerid=c.id and c.name < 'Smith'; So, what it the deletion constraint on table c? It's something like, you can't delete a row in c that has a name < 'Smith' and who matches up with an a,b row based on the other constraints and has a referencing row in the table you made the reference from, but I'm not even 100% sure of that. And heaven help you if there are subqueries. And of course, the cascade, set null and set default are even stranger.
Re: [GENERAL] Performance of Postgres via network connections
> After this is all set up, if anyone would like, I may type up an > explanation of how things were done as well as costs, for those going > through the same sort of growing pains. It's certainly been a lot of > work for us to hammer out all of the details, hopefully that would > help someone else avoid the work. That would be great. It would be fun to see some performance numbers too. And it would be a great contribution to the "user cases" that help people see the range of applications and runtime environments which have been successful. - Thomas
Re: [GENERAL] Performance of Postgres via network connections
"Steve Wolfe" <[EMAIL PROTECTED]> writes: > After this is all set up, if anyone would like, I may type up an > explanation of how things were done as well as costs, for those going > through the same sort of growing pains. It's certainly been a lot of work > for us to hammer out all of the details, hopefully that would help someone > else avoid the work. Please do --- I think a lot of people would find it interesting. regards, tom lane
