Re: general questions on Postgresql and deployment on win32 - Mailing list pgsql-general
From | Richard Huxton |
---|---|
Subject | Re: general questions on Postgresql and deployment on win32 |
Date | |
Msg-id | 41B02D9C.3030807@archonet.com Whole thread Raw |
In response to | general questions on Postgresql and deployment on win32 platform (Calvin Wood <calvin.wood@gmail.com>) |
List | pgsql-general |
Calvin Wood wrote: > Does it also mean that I must back up and restore all the databases (or > database cluster in Postgresql Speak) even if I am only interested in 1 > database? You can use pg_dump to backup individual databases (or tables etc). A file-level backup does require all databases in one "cluster" (as we call it). In fact, if you can use pg_dump to backup your databases I would recommend doing so. It gives you much more control over restoring partial databases or to other systems. > (2) WAL location > I can't seem to find a way to move WAL log to a different location other > than data/pg_xlog. You can move everything else (using tablespaces). There is a symlink maker tool for Windows (sorry, can't remember where from) but installing to the logging drivers and then setting the default tablespace to the RAID drives is probably simplest. > (3) Trigger > Is it correct to state that old and new keywords are only available to > PL/pgSQL function (but not a SQL function) and to row level trigger? Is > there anyway to refer to old and new rows for statement level trigger? The > visibility rule is also quite confusing. Can someone please clarify it in > terms of before/after and row/statement level triggers (i.e., 4 possible > permutations). There has been some discussion of what OLD/NEW would mean in a statement level trigger. I don't believe any work has been done on this yet though. Trigger functions can be written in plpgsql, plperl, pltcl, plpython or C (although I'm not sure which of these are supported on Win32 yet). As far as change visibility is concerned, statement triggers are simple. Statement/Before = no changes Statement/After = all changes For row triggers Row/Before = some changes (as the statement progresses) Row/After = all changes So - for row/before, the first row affected in a 1000-row update will see the old version of all 1000 rows. The last row affected will see the new version of 999 rows. Which order the rows are updated in is not defined. > (4) Process/thread on win32 platform > Does the Postgresql on win32 > platform use process or thread when a connection is made? I notice that the > configuration file lets you specify maximum number of connections. If I have > a very high number of persistent concurrent users (thus preventing > connection pooling from helping much), would performance suffer > significantly? PostgreSQL is process-based and this is unlikely to change (you can read the hackers mailing list archives for details). If you have a very high number of persistent concurrent users then win32 is probably not the best platform to run on - your hardware is too constrained. However, in your scenario process-based systems don't really suffer - the real bottleneck is in starting up a new process which is noticably slower on Win32 than most other platforms. Since 8.0 will be the first release of PG on Windows, I wouldn't expect performance to be as good as on the various *nix ports. It's probably too early to say where bottlenecks will be - I would recommend testing against your specific requirements. If you could share the results of such tests, I'm sure they'd be gratefully received by the community. -- Richard Huxton Archonet Ltd
pgsql-general by date: