Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, Feb 27, 2006 at 12:25:57AM +0300, Nikolay Samokhvalov wrote: > > Please help. > how? ... > PostgreSQL has very-very good documentation, but it teaches to > go Pg's way, which is not right in that sense, unfortunately... By supplying documentation patches, perhaps ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Wish: remove ancient constructs from Postgres
Am Sonntag, 26. Februar 2006 21:24 schrieb Neil Conway: > I think a better approach would be to introduce the concept of "SQL > dialects", similar to "--std=..." in GCC or SQL modes in MySQL 5. That > would help people who want to write standard-compliant applications > while not inconveniencing those who don't care. Such a thing has been discussed from time to time but in reality you wouldn't get useful results from it because just about any application will violate the standard somewhere. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Which indexes does a query use?
Chris Velevitch wrote: Are you saying that the strategy pg uses is dynamic, in that as the size of the table grows the strategy changes? The planner is quite dynamic, and what strategy it comes up with will depend not just on the size of the table, but other things as well, even on the particular constants in your comparisons. For instance, I think your original query had: where activity_user_id = 2 If the table statistics show that 2 is a very common value for that column, the planner will not use the index, as it will not save enough. (I think I have that right.) - John D. Burger MITRE ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] majordomo unmaintained, postmaster emails ignored?
# [EMAIL PROTECTED] / 2006-02-26 19:01:58 -0400:
> 'k, I just checked all the lists you listed, and you are subscribed to
> each of them ... are you not receiving messages?
I'm not receiving messages because I'm subscribed with nomail.
That's not the problem however. I want to receive the list traffic
to a different set of addresses, and that stalled ("the request must
be approved by the moderators"), as well as my attempts to gain
pgsql-docs-owner@'s and postmaster@'s attention.
Does anyone read mail for the pgsql--owner@ and postmaster@
aliases? Does anyone pay attention to the approval queue?
Anyway, here's a few snippets from my last year's email
conversations with [EMAIL PROTECTED]
My subscription requests:
: Date: Sat, 24 Sep 2005 12:17:37 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
:
: subscribe-set pgsql-docs noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-general noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-hackers noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-performance noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-sql noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-docs nomail [EMAIL PROTECTED]
: subscribe-set pgsql-general nomail [EMAIL PROTECTED]
: subscribe-set pgsql-hackers nomail [EMAIL PROTECTED]
: subscribe-set pgsql-performance nomail [EMAIL PROTECTED]
: subscribe-set pgsql-sql nomail [EMAIL PROTECTED]
Majordomo replied with the usual batch of CONFIRM messages, one of
which was:
: Date: Sat, 24 Sep 2005 07:17:39 -0300
: From: [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Subject: CA86-08AC-51A7 : CONFIRM from pgsql-general (subscribe)
:
: __
: The following request
:
: "subscribe-set pgsql-general noprefix [EMAIL PROTECTED]"
:
: was sent to
: by Roman Neuhauser <[EMAIL PROTECTED]>.
:
: To accept or reject this request, please do one of the following:
:
: 1. If you have web browsing capability, visit
:
:and follow the instructions there.
:
: 2. Reply to [EMAIL PROTECTED]
:with one of the following two commands in the body of the message:
:
: accept
: reject
:
:(The number CA86-08AC-51A7 must be in the Subject header)
:
: 3. Reply to [EMAIL PROTECTED]
:with one of the following two commands in the body of the message:
:
: accept CA86-08AC-51A7
: reject CA86-08AC-51A7
:
: Your confirmation is required for the following reason(s):
:
: Roman Neuhauser <[EMAIL PROTECTED]> issued a command
: that affects another address ([EMAIL PROTECTED]).
:
:
: If you do not respond within 4 days, a reminder will be sent.
:
: If you do not respond within 7 days, this token will expire,
: and the request will not be completed.
:
: If you would like to communicate with a person,
: send mail to [EMAIL PROTECTED]
I replied to that with:
: Date: Sat, 24 Sep 2005 12:37:28 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
: Subject: Re: CA86-08AC-51A7 : CONFIRM from pgsql-general (subscribe)
:
: accept
To which majordomo said:
: Date: Sat, 24 Sep 2005 07:37:29 -0300
: From: [EMAIL PROTECTED]
: To: Roman Neuhauser <[EMAIL PROTECTED]>
: Subject: Majordomo results: Re: CA86-08AC-51A7 : CONFIRM from pgsql-
:
:
: accept
: The accept command for token CA86-08AC-51A7 succeeded,
: but further approval is needed.
:
: Now the request must be approved by the moderators.
: The results will be mailed to you after this is done.
:
:
:
: Valid commands processed: 1
: 0 succeeded, 1 stalled, and 0 failed.
:
:
: Use the following command:
: sessioninfo 12bbdbfc049f53e9c1782cc9c10c6310e23e504f
: to see technical information about this session.
And that was the end of the conversation, I'm still waiting for a
reply to my message to postmaster@ from December, and another one to
pgsql-docs-owner@ from last August (covering the same problem):
: Date: Wed, 3 Aug 2005 00:40:15 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
: Subject: majordomo command processing problems?
:
: Hello,
:
: I tried to subscribe to pgsql-docs seven days ago:
:
: subscribe pgsql-docs [EMAIL PROTECTED]
: The subscribe command did not succeed.
:
: The request
: "subscribe pgsql-docs [EMAIL PROTECTED]"
: must be confirmed by
: [EMAIL PROTECTED]
: and approved by the moderators. Confirmation instructions have been
: mailed in a separate message.
:
:
Re: [GENERAL] Operator for int8 array
"S.Thanga Prakash" <[EMAIL PROTECTED]> writes: > We are already in the process of migrating toward 8.1 . > For existing support, we like to support with 7.1.3 . No, just stop right there; your reasonable-sounding premise is utterly not reasonable. You should be making every possible effort to get any existing 7.1 databases decommissioned. NOW. Not tomorrow, not next week. If you have data that is critical enough to worry about having a transition process, get it out of there. Expending further effort to "support" continued use of an inherently unreliable database is a disservice to your customers. Sooner or later it *will* eat their data. (Not "might"; WILL. Are you familiar with the XID wraparound problem?) You've been warned. regards, tom lane PS: if you have application compatibility issues that prevent an immediate migration to 8.*, consider using PG 7.2.8 as a stopgap solution. 7.2.* is not supported anymore either, but at least it avoids the XID wraparound gotcha; and the later 7.2.* releases fix a lot of other critical bugs. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On 2/27/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Sonntag, 26. Februar 2006 21:24 schrieb Neil Conway: > > I think a better approach would be to introduce the concept of "SQL > > dialects", similar to "--std=..." in GCC or SQL modes in MySQL 5. That > > would help people who want to write standard-compliant applications > > while not inconveniencing those who don't care. > > Such a thing has been discussed from time to time but in reality you wouldn't > get useful results from it because just about any application will violate > the standard somewhere. > so, maybe it's better to forget about SQL:2003 at all? please, remember that many people use Postgres for educational purposes. Aren't you afraid of that in the future these people will switch to MySQL because of ability to work in standard way?.. -- Best regards, Nikolay ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On 2/27/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > The alternatives to distinct on are painful. They are generally both harder > to read and run slower. > 'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it produses unpredictable result, as 'ORDER BY random()' does. When newbie types 'random()', he understands what he is doing, but it's not the case for 'DISTINCT ON' and can lead to mistakes. -- Best regards, Nikolay ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote: > On 2/27/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > The alternatives to distinct on are painful. They are generally both harder > to read and run slower. > >'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it >produses unpredictable result, as 'ORDER BY random()' does. And so does UNION in the standard under some circumstances (look at anywhere in the spec that a query expression is possibly non-deterministic), so I think that's a weak argument. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On 2/27/06, Stephan Szabo <[EMAIL PROTECTED]> wrote: > > On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote: > > > On 2/27/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > > The alternatives to distinct on are painful. They are generally both harder > > to read and run slower. > > > > >'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it > >produses unpredictable result, as 'ORDER BY random()' does. > > And so does UNION in the standard under some circumstances (look at > anywhere in the spec that a query expression is possibly > non-deterministic), so I think that's a weak argument. > it's completely different thing. look at the spec and you'll understand the difference. in two words, with 'DISTINCT ON' we lose some values (from some columns), when UNION not (it just removes duplicates, comparing _entire_ rows). -- Best regards, Nikolay ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, Feb 27, 2006 at 06:26:02PM +0300, Nikolay Samokhvalov wrote: > On 2/27/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > > Such a thing has been discussed from time to time but in reality you > > wouldn't > > get useful results from it because just about any application will violate > > the standard somewhere. > > > so, maybe it's better to forget about SQL:2003 at all? > please, remember that many people use Postgres for educational > purposes. Aren't you afraid of that in the future these people will > switch to MySQL because of ability to work in standard way?.. Huh? We should ofcourse try to implement SQL:2003 wherever we can, but to say this means we need to throw out anything not mentioned is silly. For example, CREATE INDEX is not in SQL:2003, are you seriously suggesting we remove it? We implement many extensions to SQL like user-defined operators, aggregates and casts as well as tablespaces. They are all useful and work well and don't prevent us from supporting all of SQL:2003, so why remove them? Also, we are generally more standards compliant than MySQL so I'm not sure using them makes for a good argument. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On 2/27/06, Martijn van Oosterhout wrote: > Huh? We should ofcourse try to implement SQL:2003 wherever we can, but > to say this means we need to throw out anything not mentioned is silly. > For example, CREATE INDEX is not in SQL:2003, are you seriously > suggesting we remove it? i didn't suggest removing such things. I know that there are many must-have things that standard misses (limit/offset for example), but (as i wrote...) Postgres has stuff that just duplicate standard constuctions (such as type casting with ::). It would very great if we have ability to restrict (not remove) them somehow. moreover, there are things that are implemented in non-standard way... as ILIKE. I know, that work on COLLATE support is in progress (right?) and it's very good, ILIKE is very painful thing for those who migrated from other DBMS. > > We implement many extensions to SQL like user-defined operators, > aggregates and casts as well as tablespaces. They are all useful and > work well and don't prevent us from supporting all of SQL:2003, so why > remove them? Please, do not incriminate me all deadly sins :-) I know where is the power of Postgres lies. > > Also, we are generally more standards compliant than MySQL so I'm not > sure using them makes for a good argument. Surely, MySQL is weak, but people work on it, money are being spent... Among other things, ability to set up 'SQL mode' is one of advertising tools which helps to fight with competitors. -- Best regards, Nikolay ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, Feb 27, 2006 at 06:59:21PM +0300, Nikolay Samokhvalov wrote: > On 2/27/06, Stephan Szabo <[EMAIL PROTECTED]> wrote: > > >'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it > > >produses unpredictable result, as 'ORDER BY random()' does. > > > > And so does UNION in the standard under some circumstances (look at > > anywhere in the spec that a query expression is possibly > > non-deterministic), so I think that's a weak argument. > > > it's completely different thing. look at the spec and you'll > understand the difference. in two words, with 'DISTINCT ON' we lose > some values (from some columns), when UNION not (it just removes > duplicates, comparing _entire_ rows). Wait, you're complaining because SQL lets you produce non-deterministic results? There are plenty or way to acheive this in standard SQL too. This statement: select pronargs, first( cast(prolang as integer) ) from pg_proc group by pronargs; Produces non-deterministic results also, just like DISTINCT ON (). Using LIMIT/OFFSET with an underspecified ORDER BY produces "unpredicatble" results. We provide the tools, but if people want aim them at their feet and blow them off, that's not something we can do anything about. If anything, it seems you're arguing for the removal of the random() function because it's non-deterministic. Hey, and sometimes I want a non-deterministic output. It's nice postgresql can give me that too... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [GENERAL] ltree + gist index performance degrades significantly over a night
Tsearch2 searches for whole words, and is designed with language in mind, yes? I'm looking for consecutive characters in words or serial numbers, etc. As for support, the same guys who wrote Tsearch2 wrote ltree. Can't go wrong there! Here's the solution to this problem: As usual, operator error. :( For some reason I thought it would be a good idea to cluster the table on the item_id index... What in the world was I thinking? When I clustered the search table on the search_vector index (which makes the most sense, yes?) it seemed to bring actual performance in-line with the type of performance I imagined that I would receive. I could probably get even better performance out of the table, at the cost of a significant increase in table and index size, by chopping up the columns into smaller chunks. "Hello World" would yield 'h.e.l.l.o.w.o.r.l.d' 'e.l.l.o.w.o.r.l.d' 'l.l.o.w.o.r.l.d' 'l.o.w.o.r.l.d' 'o.w.o.r.l.d' 'w.o.r.l.d' 'o.r.l.d' 'r.l.d' and using a wildcard search "search_vector ~ 'o.r.l.*'" would jump right to the vectors which start with "o.r.l" ... Thanks for all the responses! They did get my head pointed in the right direction. CG --- "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > On Fri, Feb 24, 2006 at 09:02:04AM -0800, CG wrote: > > I have a search table which I use for partial-match text searches: > > > For a string "Hello World" the ltree is created like 'h.e.l.l.o.w.o.r.l.d' > ... > > If I wanted to find all rows with "orl" in them i would construct an lquery > > like '*.o.r.l.*' and use the "~" operator in the where clause. I would link > to > > the table "items" by the item_id ... > > Is there some reason you can't use tsearch2? I suspect it would probably > work better; if nothing else you'd probably get better support since a > lot more people use it. > -- > Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] > Pervasive Software http://pervasive.comwork: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] problem with windows xp sp2 and postgres-8.1.3
Hello Guys, first of all, great effort from you this tool. Problem exists with following config: - Windows XP Pro, SP2 (English). - PostgreSQL-8.1.3 - lot of development programs, and IDE-s (for the clients i am working unfortunately they are windoz-based :-(...). Same problem occurs as described here and here. Could you have an assist? Magnus (Magnus Hagander), would you have any idea about it? Problem description: When starting the service: the following error occurs(can be read from Application Event): ="could not create inherited socket: error code 10022". = As i tried again manually(postmaster...), had the same problem. I turned off my firewall services, windows security center firewall and antivirus check (automatic updates are on), but i got the same error. Ok, deleted the postgres, deleted the user, deleted registry settings for postgres. Reinstalled and tried to make it run. Unfortunately the same error happened. It is a windows-based network address bind problem, described below: = WSAEINVAL 10022Invalid argumentSome invalid argument was supplied (for example, specifying an invalid level to the setsockopt function). In some instances, it also refers to the current state of the socket—for instance, calling accept on a socket that is not listening. Header Declared in Winsock2.h= Thanks, m$ guys, was really helpful. :-( The problem exists since i upgraded (unfortunately i had to, not wanted) from XP-SP1 to XP-SP2. Before that it was Postgres-8.0.4 installed, worked fine, seemed really cool. BUT, times and development environment (and os-s) are changing. :-( Can it have anything related to windows-socket bind problems with Windows-XP-SP2 integrated firewalls however it is disabled? Thanks in advance, István BEGIN:VCARD VERSION:2.1 N:Nagy;István;Zoltán FN:István Zoltán Nagy NICKNAME:istvan ORG:B2B-4U GmbH ADR;WORK:;;Gutenberg Str. 24;Szeged;Csongrad;6722;Hungary LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Gutenberg Str. 24=0D=0ASzeged, Csongrad 6722=0D=0AHungary ADR;HOME:;;Nibelungenallee 13;Frankfurt am Main;Hessen;60318;Germany LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Nibelungenallee 13=0D=0AFrankfurt am Main, Hessen 60318=0D=0AGermany URL;WORK:http://www.b2b-4u.hu EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:20060227T080414Z END:VCARD ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote: >it's completely different thing. look at the spec and you'll >understand the difference. in two words, with 'DISTINCT ON' we lose >some values (from some columns), when UNION not (it just removes >duplicates, comparing _entire_ rows). No it's not, really. Read the spec. The output of a union on a text field is non-deterministic (due to some collation choices). This means that the output of the query may be determined by an effectively random choice of which value to use. Basically AFAICT something like (modulo simple errors): select foo from ( select foo from tablea union select foo from tableb ) where foo = 'A' collate case_sensitive can give different results in the case of tablea having 'A' and tableb having 'a' if the union is using a case insensitive comparison. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ltree + gist index performance degrades significantly over a night
On Mon, Feb 27, 2006 at 09:14:40AM -0800, CG <[EMAIL PROTECTED]> wrote: > I could probably get even better performance out of the table, at the cost of > a > significant increase in table and index size, by chopping up the columns into > smaller chunks. > > "Hello World" would yield > > 'h.e.l.l.o.w.o.r.l.d' > 'e.l.l.o.w.o.r.l.d' > 'l.l.o.w.o.r.l.d' > 'l.o.w.o.r.l.d' > 'o.w.o.r.l.d' > 'w.o.r.l.d' > 'o.r.l.d' > 'r.l.d' > > and using a wildcard search "search_vector ~ 'o.r.l.*'" would jump right to > the > vectors which start with "o.r.l" ... But with this approch you'd be fine with a normal varchar_ops btree index for textfields and searching using "like 'world%'", wouldn't you? Or is the ltree approch more efficient? I'm not trying to be smart-assed, it's a naive question, since I'm looking for an efficient substring search solution in postgresql myself. regards, bkw ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] A question about Vacuum analyze
Thank you very much for all your inputs. I believe "analyze" is the one I should use . Quoth [EMAIL PROTECTED] (Emi Lu): no. the suggestion was that a VACUUM is not needed, but that an ANALYZE might be. Thank you gnari for your answer. But I am a bit confused about not running vacuum but only "analyze". Can I seperate these two operations? I guess "vacuum analyze" do both vacuum and analyze. Or "EXPLAIN ANALYZE" can do it for me? EXPLAIN, ANALYZE, and VACUUM are different things; ANALYZE gets used in two different contexts... 1. VACUUM is what cleans dead tuples out of tables. e.g. VACUUM my_table; 2. VACUUM ANALYZE cleans out dead tuples and recalculates data distributions e.g. VACUUM ANALYZE my_table; 3. EXPLAIN describes query plans e.g. EXPLAIN select * from my_table; 4. EXPLAIN ANALYZE compares query plan estimates to real results e.g. EXPLAIN ANALYZE select * from my_table; 5. ANALYZE recalculates data distributions (as in 2, but without cleaning out dead tuples). e.g. ANALYZE my_table; Pointedly, EXPLAIN ANALYZE is entirely distinct from ANALYZE and VACUUM ANALYZE... ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] ltree + gist index performance degrades significantly over a night
That would do the job, wouldn't it? :) I don't think it's a naive question at all. Its quite a good question, and the solution you suggest is a good option to have, and would probably work better than the single-vector ltree index for simple substring matching. In my case, the ltree+gist index table actually contains more pages than the table of data itself. I'd need to see if the space required for the varchar+btree tables are comparible, better, or worse than the ltree+gist tables with regards to size. Now that I think about it, building substrings out of ltree nodes would be incredible overkill comapred to the effetiveness of the varchar+btree. The extra advantages of ltree are the ability to match and extract nodes in a path based not only on contents but also proximity, and aggregate on those characteristics. In my case this might be good for serial numbers where each digit or grouping of digits have special values which would be used to aggregate on. The ltree method was suggested to me a while back when I was frustrated with the performance of "like '%something%'" ... --- Bernhard Weisshuhn <[EMAIL PROTECTED]> wrote: > On Mon, Feb 27, 2006 at 09:14:40AM -0800, CG <[EMAIL PROTECTED]> wrote: > > > I could probably get even better performance out of the table, at the cost > of a > > significant increase in table and index size, by chopping up the columns > into > > smaller chunks. > > > > "Hello World" would yield > > > > 'h.e.l.l.o.w.o.r.l.d' > > 'e.l.l.o.w.o.r.l.d' > > 'l.l.o.w.o.r.l.d' > > 'l.o.w.o.r.l.d' > > 'o.w.o.r.l.d' > > 'w.o.r.l.d' > > 'o.r.l.d' > > 'r.l.d' > > > > and using a wildcard search "search_vector ~ 'o.r.l.*'" would jump right to > the > > vectors which start with "o.r.l" ... > > But with this approch you'd be fine with a normal varchar_ops btree index > for textfields and searching using "like 'world%'", wouldn't you? > Or is the ltree approch more efficient? > > I'm not trying to be smart-assed, it's a naive question, since I'm > looking for an efficient substring search solution in postgresql myself. > > regards, > bkw > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On Mon, Feb 27, 2006 at 18:34:16 +0300, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: > On 2/27/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > > The alternatives to distinct on are painful. They are generally both harder > > to read and run slower. > > > > 'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it > produses unpredictable result, as 'ORDER BY random()' does. > > When newbie types 'random()', he understands what he is doing, but > it's not the case for 'DISTINCT ON' and can lead to mistakes. The documentation for DISTINCT ON is clear about this: DISTINCT ON ( expression [, ...] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. The DISTINCT ON expressions are interpreted using the same rules as for ORDER BY (see above). Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. For example, I doubt the newbie understands random() as well as DISTINCT ON on the first go around. In some uses random() is evaluated per tuple and in others it isn't. In particular it probably isn't obvious to newbies what the semantics of the following is: SELECT a FROM b WHERE a > random(); ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] Breaking Path/Polygon Data into Pieces
Hi, 2 weeks ago, a user in -tr-genel asked for a function to break path/polygon type data into pieces. He also told that, it creates a bottleneck in the network traffic when they try to receive rows with polygon data of thousands of nodes, while it's enough for them to have polygons partially. AFAIK, there doesn't exist such functions in PostgreSQL. (Please correct me if I'm wrong.) For this purpose, I've coded two simple C procedures: polygon part(polygon, offset, limit) pathpart(path, offset, limit) I thought it would be nice to see these functions in PostgreSQL and wanted to ask for other users (and developers) ideas. Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ltree + gist index performance degrades significantly over a night
On Mon, Feb 27, 2006 at 10:27:20AM -0800, CG <[EMAIL PROTECTED]> wrote: > [...] I'd need to see if the space required for the varchar+btree tables are > comparible, better, or worse than the ltree+gist tables with regards to size. Please test this, I'm guessing (hoping actually) that having bazillions of combinations of 26 (or so) characters (ltree labels) might be consuming less space than having bazillions of substings in the database. Or maybe some clever combination of both approaches? If you find out something interesting, please let me know. regards, bkw ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Question about COPY to/from
Hi Stephen, We have millions of record and would like to insert into a table. I remebered people mentioned that "COPY" is the most effecient way to insert data, right? If not, which is it, pg_restore? By the way, does it have to be superuser to run copy to and from? COPY is what you want. It doesn't have to be done as superuser if it's being sent over an existing connection to the database. The way to do this would be something like: zcat $file | psql -d db -h host -c "COPY $TABLE FROM STDIN;" through command line "... copy ... stdin" works fine for me. However, running "psql -d db -h ... from STDID", I believe we are forced to type the password through prompt command line. Since our data population task is through cronjob, is there a way, we can run "COPY ... STDIN" by explicitly specifying password so that no human intervention? Probably the easiest to do would be to jump into psql and do '\h copy'. Superuser's privileges is required under "psql>". Note that psql also has a '\copy' command which allows the same syntax but you can specify a file relative to the psql client. COPY $TABLE FROM 'file' requires superuser privileges and the file be on the server and the path to 'file' be relative to the server process. That would technically be a bit faster as the data wouldn't have to go across a socket but requires superuser and the file be on the server already... Thanks a lot, Emi ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] majordomo unmaintained, postmaster emails ignored?
Can you try something more recent then "last year"?
On Mon, 27 Feb 2006, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-02-26 19:01:58 -0400:
'k, I just checked all the lists you listed, and you are subscribed to
each of them ... are you not receiving messages?
I'm not receiving messages because I'm subscribed with nomail.
That's not the problem however. I want to receive the list traffic
to a different set of addresses, and that stalled ("the request must
be approved by the moderators"), as well as my attempts to gain
pgsql-docs-owner@'s and postmaster@'s attention.
Does anyone read mail for the pgsql--owner@ and postmaster@
aliases? Does anyone pay attention to the approval queue?
Anyway, here's a few snippets from my last year's email
conversations with [EMAIL PROTECTED]
My subscription requests:
: Date: Sat, 24 Sep 2005 12:17:37 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
:
: subscribe-set pgsql-docs noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-general noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-hackers noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-performance noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-sql noprefix [EMAIL PROTECTED]
: subscribe-set pgsql-docs nomail [EMAIL PROTECTED]
: subscribe-set pgsql-general nomail [EMAIL PROTECTED]
: subscribe-set pgsql-hackers nomail [EMAIL PROTECTED]
: subscribe-set pgsql-performance nomail [EMAIL PROTECTED]
: subscribe-set pgsql-sql nomail [EMAIL PROTECTED]
Majordomo replied with the usual batch of CONFIRM messages, one of
which was:
: Date: Sat, 24 Sep 2005 07:17:39 -0300
: From: [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Subject: CA86-08AC-51A7 : CONFIRM from pgsql-general (subscribe)
:
: __
: The following request
:
: "subscribe-set pgsql-general noprefix [EMAIL PROTECTED]"
:
: was sent to
: by Roman Neuhauser <[EMAIL PROTECTED]>.
:
: To accept or reject this request, please do one of the following:
:
: 1. If you have web browsing capability, visit
:
:and follow the instructions there.
:
: 2. Reply to [EMAIL PROTECTED]
:with one of the following two commands in the body of the message:
:
: accept
: reject
:
:(The number CA86-08AC-51A7 must be in the Subject header)
:
: 3. Reply to [EMAIL PROTECTED]
:with one of the following two commands in the body of the message:
:
: accept CA86-08AC-51A7
: reject CA86-08AC-51A7
:
: Your confirmation is required for the following reason(s):
:
: Roman Neuhauser <[EMAIL PROTECTED]> issued a command
: that affects another address ([EMAIL PROTECTED]).
:
:
: If you do not respond within 4 days, a reminder will be sent.
:
: If you do not respond within 7 days, this token will expire,
: and the request will not be completed.
:
: If you would like to communicate with a person,
: send mail to [EMAIL PROTECTED]
I replied to that with:
: Date: Sat, 24 Sep 2005 12:37:28 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
: Subject: Re: CA86-08AC-51A7 : CONFIRM from pgsql-general (subscribe)
:
: accept
To which majordomo said:
: Date: Sat, 24 Sep 2005 07:37:29 -0300
: From: [EMAIL PROTECTED]
: To: Roman Neuhauser <[EMAIL PROTECTED]>
: Subject: Majordomo results: Re: CA86-08AC-51A7 : CONFIRM from pgsql-
:
:
: accept
: The accept command for token CA86-08AC-51A7 succeeded,
: but further approval is needed.
:
: Now the request must be approved by the moderators.
: The results will be mailed to you after this is done.
:
:
:
: Valid commands processed: 1
: 0 succeeded, 1 stalled, and 0 failed.
:
:
: Use the following command:
: sessioninfo 12bbdbfc049f53e9c1782cc9c10c6310e23e504f
: to see technical information about this session.
And that was the end of the conversation, I'm still waiting for a
reply to my message to postmaster@ from December, and another one to
pgsql-docs-owner@ from last August (covering the same problem):
: Date: Wed, 3 Aug 2005 00:40:15 +0200
: From: Roman Neuhauser <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
: Subject: majordomo command processing problems?
:
: Hello,
:
: I tried to subscribe to pgsql-docs seven days ago:
:
: subscribe pgsql-docs [EMAIL PROTECTED]
: The subscribe command did not succeed.
:
: The request
: "subscribe pgsql-docs [EMAIL PROTECTED]"
: must be confirmed by
: [EMAIL PROTECTED]
: and approved by the moderators. Confirmation instructions have been
: mailed in a separate message.
:
: And then:
:
: accept 9E0C-7
Re: [GENERAL] Question about COPY to/from
Emi Lu <[EMAIL PROTECTED]> writes: > However, running "psql -d db -h ... from STDID", I believe we are > forced to type the password through prompt command line. Since our data > population task is through cronjob, is there a way, we can run "COPY ... > STDIN" by explicitly specifying password so that no human intervention? Best way is to put the password in ~/.pgpass file belonging to the account that runs the cron job. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Breaking Path/Polygon Data into Pieces
On Mon, Feb 27, 2006 at 08:41:52PM +0200, Volkan YAZICI wrote: > 2 weeks ago, a user in -tr-genel asked for a function to break > path/polygon type data into pieces. He also told that, it creates a > bottleneck in the network traffic when they try to receive rows with > polygon data of thousands of nodes, while it's enough for them to > have polygons partially. > > AFAIK, there doesn't exist such functions in PostgreSQL. (Please > correct me if I'm wrong.) For this purpose, I've coded two simple > C procedures: > > polygon part(polygon, offset, limit) > pathpart(path, offset, limit) PostGIS has geometry accessors that might work. You'd need to be using PostGIS geometry types instead of the PostgreSQL types. http://postgis.refractions.net/docs/ch06.html Are the following examples anything like what the user in tr-general was looking for? postgis=> SELECT AsText(geom) FROM foo; astext -- POLYGON((0 0,10 0,10 10,0 10,0 0),(1 1,9 1,9 9,1 9,1 1)) (1 row) postgis=> SELECT AsText(ExteriorRing(geom)) FROM foo; astext - LINESTRING(0 0,10 0,10 10,0 10,0 0) (1 row) postgis=> SELECT AsText(InteriorRingN(geom, 1)) FROM foo; astext - LINESTRING(1 1,9 1,9 9,1 9,1 1) (1 row) postgis=> SELECT n, AsText(PointN(ring, n)) postgis-> FROM (SELECT ExteriorRing(geom) AS ring FROM foo) AS s, postgis-> generate_series(1, 2) AS g(n); n | astext ---+- 1 | POINT(0 0) 2 | POINT(10 0) (2 rows) postgis=> SELECT AsText(MakeLine(PointN(ring, n))) postgis-> FROM (SELECT ExteriorRing(geom) AS ring FROM foo) AS s, postgis-> generate_series(1, 2) AS g(n); astext -- LINESTRING(0 0,10 0) (1 row) postgis=> SELECT AsText(line_substring(ExteriorRing(geom), 0, 0.25)) postgis-> FROM foo; astext -- LINESTRING(0 0,10 0) (1 row) -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] audit tables adding columns
I am using triggers and table inheritance for my audit tables. Here is the function I am using its straight copy from the docs. CREATE OR REPLACE FUNCTION process_reward_audit() RETURNS "trigger" AS $BODY$ BEGIN IF (TG_OP = 'INSERT') THEN INSERT INTO reward_audit SELECT NEW.*, NOW(), user, 'I'; RETURN NEW; ELSEIF (TG_OP = 'UPDATE') THEN INSERT INTO reward_audit SELECT NEW.*,NOW(), user, 'U'; RETURN NEW; ELSEIF (TG_OP = 'DELETE') THEN INSERT INTO reward_audit SELECT OLD.*,NOW(), user, 'D'; RETURN OLD; END IF; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; The problem I am having is if I have to add a column to the table I am auditing, the new column gets added to the end of the parent table AND to the child audit table. This causes my function to die because NEW.* now has the new column that is trying to be inserted into date column of the audit table. Since postgres doesn't allow you to reorder column I can't move the new column in the audit table so I have to drop my audit table and recreate it. I am basically at the initial stages of development on a web app so I don't care about the data in the audit table, but I will when it goes live. The ideal solution would be if I could change the above function to magically handle new columns I can't think of anyway this is going to happen. I am thinking I'll end up writing a script to partial automate the dump of and recreation of the audit table, but I thought I'd put this out there and see if wonderfully people of the postgres community had some magically solution. joe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Wish: remove ancient constructs from Postgres
On 02/26/2006-10:36AM, Andrus Moor wrote: > > It is difficult to write standard-compliant code in Postgres. > There are a lot of constructs which have SQL equivalents but are still used > widely, even in samples in docs! > > For example, there are suggestions using > > now()::CHAR!=foo > > while the correct way is > > CAST(CURRENT_DATE AS CHAR)<>foo > > now() function, :: and != operators should be removed from language. > > I like the Python logic: there is one way Actually the python logic is "There should be one-- and preferably only one --obvious way to do it." Perhaps the suggestion should be to only use the SQL standard forms in the documentation, making them the 'obvious' way. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] In case nobody has seen this survey from Sun ...
Just got posted to the FreeBSD list ... has several questions that revolve around the BSD vs GPL licensing, and somewhere that 'omit' PostgreSQL as an OS option (while others include it) ... http://enews.sun.com/CTServlet?id=103018442-968290480:1141071714252 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] Dumping functions
How can I dump a function definition with pg_dump? Background: We often need to create objects that are all relevant to only a specific project. Sometimes it is a single table. Other times there are many tables, indexes, views, rules, triggers and functions. All the objects share a unique substring that identifies the project so automatically creating the list is easy. When I use pg_dump to dump a table I will by default also get the associated indexes, rules and triggers. Views can be dumped just like tables. So all I need to do to archive the whole mess is to automate the dump of the functions. Ideas? Cheers, Steve ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] postgresql documentation
On Sun, 26 Feb 2006, Randy Yates wrote: I've noticed that the PDF version of the manuals for 8.0 and 8.1 are lacking bookmarks and/or TOC and document reference links. If this is generated via LaTeX, such links oculd easily be incorporated via the hyperref package. It would make the document much easier to navigate. The 7.4 and 8.0 manuals are missing the bookmarks/TOC, but the 8.1 manual does have them. Kris Jurka ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Wish: remove ancient constructs from Postgres
> Aren't you afraid of that in the future these people will switch to MySQL because of ability to work in standard way?.. You're joking, right? At least I had a good laugh. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] How many postmasters should be running?
Hello, A few minutes ago, we were surprised to find a second postmaster process running on our database machine as a child of the original postmaster. The child postmaster was around for about a minute then disappeared. This is a Opteron machine running RedHat AS4 with Postgres 8.1.2. Does the postmaster process ever spawn a child postmaster? Is this normal? Thanks, Stuart If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] postgresql documentation
Kris Jurka <[EMAIL PROTECTED]> writes: > On Sun, 26 Feb 2006, Randy Yates wrote: > >> I've noticed that the PDF version of the manuals for 8.0 and 8.1 >> are lacking bookmarks and/or TOC and document reference links. If >> this is generated via LaTeX, such links oculd easily be incorporated >> via the hyperref package. It would make the document much easier to >> navigate. > > The 7.4 and 8.0 manuals are missing the bookmarks/TOC, but the 8.1 > manual does have them. > > Kris Jurka I stand corrected - I was only using the 8.0 documentation. MUCH better! -- % Randy Yates % "And all that I can do %% Fuquay-Varina, NC% is say I'm sorry, %%% 919-577-9882% that's the way it goes..." <[EMAIL PROTECTED]> % Getting To The Point', *Balance of Power*, ELO http://home.earthlink.net/~yatescr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] How many postmasters should be running?
On Mon, Feb 27, 2006 at 09:05:51PM -0500, Stock, Stuart wrote: > A few minutes ago, we were surprised to find a second postmaster process > running on our database machine as a child of the original postmaster. The > child postmaster was around for about a minute then disappeared. This is a > Opteron machine running RedHat AS4 with Postgres 8.1.2. > > Does the postmaster process ever spawn a child postmaster? Is this normal? Each connection causes the postmaster to fork a new process to handle that connection. When the connection ends so does that process; that might be what you saw. For more information see the "Monitoring Database Activity" and postmaster documentation: http://www.postgresql.org/docs/8.1/interactive/monitoring.html http://www.postgresql.org/docs/8.1/interactive/app-postmaster.html -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] rotate records
Michael,
Thank you very much for your response.
I tried your solutions but still it looks like it doesn't work when I
delete random records.
select * from foo;
id | val
+-
1 | 13
2 | 14
3 | 15
(3 rows)
delete from foo where val = '13';
DELETE 1
delete from foo where val = '15';
DELETE 1
select * from foo;
id | val
+-
2 | 14
(1 row)
insert into foo (val) values ('16');
INSERT 34533 1
psimc_db=# select * from foo;
id | val
+-
2 | 14
1 | 16
(2 rows)
insert into foo (val) values ('17');
INSERT 34534 1
psimc_db=#
psimc_db=# select * from foo;
id | val
+-
1 | 16
2 | 17
As you can see the record with value '14' is gone without explicit
delete, which is not what I expected. Do you have any ideas on how to
avoid this?
Natasha Galkina.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: Saturday, February 25, 2006 10:39 AM
To: Natasha Galkina
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] rotate records
On Sat, Feb 25, 2006 at 10:12:38AM -0700, Michael Fuhr wrote:
> > If it is not correct, how can I rotate the records in the table?
>
> One way would be to use a trigger to delete records having the same
> event_id as the record being inserted.
I should mention that with the example I posted you can still get
duplicate key violations if enough concurrent transactions insert
into the table at the same time. I'll have to think a little more
about the best way to avoid that.
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] rotate records
Hi all, I am facing performance issues even with less than 3000 records, I am using Triggers/SPs in all the tables. What could be the problem. Any idea it is good to use triggers w.r.t performance? Regards, Jeeva.K ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] rotate records
On Mon, Feb 27, 2006 at 07:39:22PM -0800, Natasha Galkina wrote: > I tried your solutions but still it looks like it doesn't work when I > delete random records. [...] > As you can see the record with value '14' is gone without explicit > delete, which is not what I expected. Do you have any ideas on how to > avoid this? Deletes are indeed a problem with the simple example I posted. It simply re-uses the next value in the sequence, deleting any row that currently has that value; it doesn't count the number of rows and delete the excess ones. I recall past discussions about mechanisms to limit the number of rows in a table. Here's a recent message with a suggestion: http://archives.postgresql.org/pgsql-novice/2005-12/msg00323.php Before putting more thought into it I'd want to search for other past discussion. A couple of problems are efficiency and concurrency: how to quickly know which, if any, old rows to delete, and how to ensure that inserts in concurrent transactions can't result in the table having more rows than it should. -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] rotate records
On Tue, Feb 28, 2006 at 09:14:59 +0530, "Jeevanandam, Kathirvel (IE10)" <[EMAIL PROTECTED]> wrote: > Hi all, Please don't hijack existing threads to start new ones. This can cause people to miss your question and messes up the archives. Performance questions should generally be posted to the performance list. I have redirected followups to there. > > I am facing performance issues even with less than 3000 records, I am > using Triggers/SPs in all the tables. What could be the problem. > Any idea it is good to use triggers w.r.t performance? A common cause of this kind of thing is not running vacuum often enough leaving you with a lot of dead tuples. You should probably start by doing a vacuum full analyse and then showing the list some problem query sources along with explain analyse output for them. > > Regards, > Jeeva.K > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
triggers, performance Was: Re: [GENERAL] rotate records
Jeevanandam, Kathirvel (IE10) schrieb: > Hi all, > > I am facing performance issues even with less than 3000 records, I am > using Triggers/SPs in all the tables. What could be the problem. > Any idea it is good to use triggers w.r.t performance? Much to general. What triggers? (what are they doing, when are they invoked...?). Please provide much greater details with your request or nobody can help. Regards Tino PS: and try not to steal threads ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] How many postmasters should be running?
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Mon, Feb 27, 2006 at 09:05:51PM -0500, Stock, Stuart wrote: >> A few minutes ago, we were surprised to find a second postmaster process >> running on our database machine as a child of the original postmaster. > Each connection causes the postmaster to fork a new process to > handle that connection. Also, all postmaster child processes will properly identify themselves as long as you are using the appropriate ps options. (Depending on your OS, the default ps output format might just list them all as "postmaster".) Try something like "ps auxww | grep postgres" if using Linux. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
