[GENERAL] add, subtract bool type
I made some simple functions that create the operators + and - for any combination of int4's and bool's. The reasoning that propted this operator was that I wanted to use the following syntax in a query: SELECT *,((col_a == 'foo') + (col_b == 'bar')) as relevance WHERE relevance 0; The idea is that the attribute 'relevance' counts the number of matching criteria. Such functionality would be most useful in a search engine, but may have other uses. My question is two-part: 1) Is this a sane approach? 2) Might enough other people find a use that I should make a contribution somewhere (and would it be appropriate to send it to pgsql-hackers or pgsql-patches)? Is there a chance it will get incorporated into the main source? Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] maximum query length
Hi all, I have a problem related with the maximum query length ERR: query is too long. Maximum length is 16382 I'm using PostgreSQL 6.5.3 and python Is this limit in the newer releases of PostgreSQL too? Thanks for any help Jose Soares ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Extending triggers capabilities (inserted/deleted pseudo tables)
Hi! I have to migrate application from Delphi/MSSQL to Kylix/free_rdbms. One of things used in this app is INSERTED/DELETED tables in triggers. It's something like NEW and OLD records, but may contain multiple rows. My questions are: How difficult would it be to implement such a feature in PostgreSQL? What impact would it have on pgsql performance/memory reqiurements? Would it be useful for somebody else? Thanks in advance, Tom -- .signature: Too many levels of symbolic links ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Comparing fixed precision to floating
FYI -- JDBC questions should go to the pgsql-jdbc mail list. As for your problem, I think probably the easiest workaround is to explicitly cast your constants. Assuming you are using PreparedStatements, a statement of the following form should work: select * from foo where bar = ?::numeric When the parameter is bound, the resulting statement sent to the server will be: select * from foo where bar = 123.456::numeric which should work correctly. thanks, --Barry Mike Finn wrote: I am using numeric(p,s) fields in a database schema. Using queries that contain a comparison like ... where numericField = 456.789 will generate an error Unable to identify an operator '=' for types 'numeric' and 'float8' You will have to retype this query using an explicit cast and if i explicitly cast the 456.789 (456.789::numeric) it does in fact work. But how do we get around this error when using JDBC? Shouldn't =(numeric, float8) be a standard operator in postgresql? My query is a dynamically prepared statement in java where many of the constant values are user supplied and poped into the statement via pstmt.setObject(pos, valueObj, type) in the case of a numeric field the type parameter is Types.NUMERIC and the valueObj parameter is a java.math.BigDecimal. (java.math.BigDecimal is the only way I know of to represent fixed precision and scale number in java). And of course this will blow with the previous error. I do have a work around which is to force the user supplied constant (a BigDecimal) to a string and user pstmt.setString(...). Effectively this create a clause of the form ... where numericField = '456.789' but it postgres will automatically cast the right hand side to a numeric I would have expected it to be able to cast a float8 constant to a numeric as well. If there is good reason why this can't be done, could someone explain what I am missing. Else could we put a =(numeric, float8) operator on the todo list? Thanks, in advance for any help. Mike. === Mike Finn Tactical Executive Systems [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] maximum query length
Hi all, I have a problem related with the maximum query length ERR: query is too long. Maximum length is 16382 I'm using PostgreSQL 6.5.3 and python Is this limit in the newer releases of PostgreSQL too? Thanks for any help All those limits are gone. Upgrade to 7.1.3. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: 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] problems transfering databases
Hello, I'm a newbie in the postgreSQL world, so if I'm asking what's rather straightforward, I appologize. This is what I'm trying to do: my collegue and I have set up three postgreSQL databases; he has set it up on Linux RedHat 6.2, and I've been working on RedHat 6.2 as well on Solaris 7. We are trying to transfer all the data from his database to mine (my primary database is on Solaris). So, we consulted the docs, and he has used the command: pg_dumpall backups/2001-06-04db.out and sent me that file. But, when I try to load it to my database, I get the error message: obonjan[postgres- ~/tmp]%psql -f 2001-08-21db.out You are now connected to database template1. SELECT DELETE 0 DROP 'sql:2001-08-21db.out:5: ERROR: copy: line 1, Bad abstime external representation '\N psql:2001-08-21db.out:5: PQendcopy: resetting connection I thougth, it might be something to do with Solaris, but on Linux, like expected, the same error. What amd I doing wrong? Please, contact me directly, since I'm not on the mailing list. Thanks, Miroslav ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[GENERAL] SELECT FOR UPDATE
Hi all, I'm trying SELECT FOR UPDATE but I have a problem with locks. example: I have two users accessing to the same records, say... user1: DELECT * FROM table WHERE field=value FOR UPDATE --- user2: DELECT * FROM table WHERE field=value FOR UPDATE at this point user2 can't do nothing except waiting for user1 unlock recors. My question is: - Is it possible to know in advance if the records of a given query are locked, to prevent to be locked for ever? Thank for any help, Jose Soares ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] add, subtract bool type
Jeff Davis [EMAIL PROTECTED] writes: I made some simple functions that create the operators + and - for any combination of int4's and bool's. My question is two-part: 1) Is this a sane approach? It'd be less work if you made a bool-int conversion function and relied on the regular integer operators. Safer, too: this way is likely to cause the system to accept queries that do things you didn't intend. In fact, I'd personally want the conversion to not be applied by default, which means you *shouldn't* call the conversion function int4(). Functions named after the destination type are assumed to represent implicit type coercions, and will be applied without being mentioned explicitly. OTOH, if you don't care about type safety, you could achieve the same result as your operator set with just such an implicit coercion function: test71=# select 't'::bool + 44; ERROR: Unable to identify an operator '+' for types 'bool' and 'int4' You will have to retype this query using an explicit cast test71=# select 't'::bool + 't'::bool; ERROR: Unable to identify an operator '+' for types 'bool' and 'bool' You will have to retype this query using an explicit cast test71=# create function int4(bool) returns int4 as ' test71'# select case when $1 then 1 else 0 end;' language 'sql'; CREATE test71=# select 't'::bool + 44; ?column? -- 45 (1 row) test71=# select 't'::bool + 't'::bool; ?column? -- 2 (1 row) test71=# But as I said, I'd prefer to name the function something else (maybe integerize) and have to invoke it explicitly. I'm an old Pascal programmer and believe strongly that bool and int ought not be considered interchangeable: that masks too many programming errors. 2) Might enough other people find a use that I should make a contribution somewhere (and would it be appropriate to send it to pgsql-hackers or pgsql-patches)? As you can see, there's not a lot to it, at least not for low-volume applications. If you expected to invoke integerize() zillions of times, it might be worth the trouble to prepare a C-coded version of it. That would be worth contributing, since other people have asked for this same functionality. But then you'd have to get people to agree on a name for the function, and believe me that'll be the hardest part ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] problems transfering databases
Miroslav Koncar [EMAIL PROTECTED] writes: 'sql:2001-08-21db.out:5: ERROR: copy: line 1, Bad abstime external representation '\N psql:2001-08-21db.out:5: PQendcopy: resetting connection Given the weird line-wrapping of the message, I'm going to bet that the problem is that newlines in the dump file have gotten converted to DOS format (ie, \n became \r\n), and COPY is unhappy because it sees the \r as part of the data. When it echoes the data it didn't like, the presence of the \r messes up the format of the error message. Not sure *how* that happened in a Linux-to-Solaris transfer, though; what tool did you use to transfer the dump file? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[GENERAL] During dump: function not found
During a pg_dump, I got the following messages: Notice: function pgadmin_get_rows is not dumped. Reason: return type name (oid 87589805) not found. Notice: function pgadmin_get_sequence is not dumped. Reason: return type name (oid 87589772) not found. Does this simply mean that these functions will not be available if I restore from the dump file? Will these messages haunt me down the road in other ways? I'm assuming (dangerous, I know) that these functions were created by PgAdmin rather than being a part of PostgreSQL. I deleted all tables and views named pgadmin* and am trying to weed out everything created by PgAdmin. Thanks, Andrew Gould __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[GENERAL] FTI is really really slow; what am I doing wrong?
Greetings, I am trying to test out the performance of the contrib/fulltextindex package and I am getting horrid performance results. The Setup: I created a simple table, ST (id SERIAL, body varchar(1024), which is to be searched. I created the ST_FTI table, trigger and indices as per instructions in the FTI readme and C file. To populate the table, I took a flat text version of 'War and Peace' I found on the net, broke it up into sentences and inserted each sentence into ST as a row. So I have about 38,000 sentences and my ST_FTI table is about 2 million rows. The Test: There is exactly one sentence (row) that has the strings 'Newton' and 'Kepler' in it. That is my target. For a straight select on ST: select * from st where body ~* 'newton' and body ~* 'kepler'; the cost is 1100.41 BUT for an query using the FTI indices: select s.* from st s, st_fti f1, st_fti f2 where f1.string ~ '^kepler' and f2.string ~ '^newton' and s.oid = f1.id and s.oid = f2.id; the cost becomes a staggering 80628.92!!! The plans are pasted at the end of this message. Now, I have all the indices created (on id of st_fti, on string of st_fti and on oid of st). I cannot figure out why this is so much worse than the straight query. Indeed, the cost to look up a single string in the st_fti table is way high: select * from st_fti where string ~ '^kepler'; costs 36703.40, AND its doing a Seq Scan on st_fti, even though an index exists. What am I doing wrong? Is it the sheer size of the st_fti table that is causing problems? Any help would be greatly appreciated. Thanks, Paul C. FTI search NOTICE: QUERY PLAN: Merge Join (cost=80046.91..80628.92 rows=110 width=28) - Sort (cost=41827.54..41827.54 rows=19400 width=24) - Hash Join (cost=1992.80..40216.39 rows=19400 width=24) - Seq Scan on st_fti f2 (cost=0.00..36703.40 rows=19400 width=4) - Hash (cost=929.94..929.94 rows=34094 width=20) - Seq Scan on st s (cost=0.00..929.94 rows=34094 width=20) - Sort (cost=38219.37..38219.37 rows=19400 width=4) - Seq Scan on st_fti f1 (cost=0.00..36703.40 rows=19400 width=4) EXPLAIN Plain search: NOTICE: QUERY PLAN: Seq Scan on st (cost=0.00..1100.41 rows=1 width=16) EXPLAIN _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] During dump: function not found
Hi Andrew, These functions were indeed created by PgAdmin. It seems to create tables, functions, triggers and views (maybe rules too, not sure) going by the name pgadmin_xxx and pga_xxx I'm pretty sure from looking at PgAdmin 7.1.0 recently it has a menu option to remove it's tables and other constructs from a target database by itself. You might just want to run that instead of doing it yourself/ :-) Regards and best wishes, Justin Clift Andrew Gould wrote: During a pg_dump, I got the following messages: Notice: function pgadmin_get_rows is not dumped. Reason: return type name (oid 87589805) not found. Notice: function pgadmin_get_sequence is not dumped. Reason: return type name (oid 87589772) not found. Does this simply mean that these functions will not be available if I restore from the dump file? Will these messages haunt me down the road in other ways? I'm assuming (dangerous, I know) that these functions were created by PgAdmin rather than being a part of PostgreSQL. I deleted all tables and views named pgadmin* and am trying to weed out everything created by PgAdmin. Thanks, Andrew Gould __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] FTI is really really slow; what am I doing wrong?
Meant to send this to the whole list... I had vaccum'ed it, but not 'vacuum analyze' -ed it. That did the trick. Cost down to 12.09 from 80628.92. Thank you! From: Mitch Vincent [EMAIL PROTECTED] To: Paul C. [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [GENERAL] FTI is really really slow; what am I doing wrong? Date: Wed, 22 Aug 2001 11:28:04 -0400 You've vacuum analyze 'd the database, haven't you? -Mitch There is exactly one sentence (row) that has the strings 'Newton' and 'Kepler' in it. That is my target. For a straight select on ST: select * from st where body ~* 'newton' and body ~* 'kepler'; the cost is 1100.41 BUT for an query using the FTI indices: select s.* from st s, st_fti f1, st_fti f2 where f1.string ~ '^kepler' and f2.string ~ '^newton' and s.oid = f1.id and s.oid = f2.id; the cost becomes a staggering 80628.92!!! The plans are pasted at the end of this message. Now, I have all the indices created (on id of st_fti, on string of st_fti and on oid of st). I cannot figure out why this is so much worse than the straight query. Indeed, the cost to look up a single string in the st_fti table is way high: select * from st_fti where string ~ '^kepler'; costs 36703.40, AND its doing a Seq Scan on st_fti, even though an index exists. What am I doing wrong? Is it the sheer size of the st_fti table that is causing problems? Any help would be greatly appreciated. Thanks, _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ---(end of broadcast)--- TIP 3: 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] Printable report generation
On Tue, Aug 21, 2001 at 10:25:35AM +0200, Tony Grant wrote:
For example, say I've got a postgresql database of client information
(names, addresses, etc.), and I want to use this information to generate
envelopes for mailouts. As far as my understanding goes, such
functionality is not provided by postgresql itself.
I have the same problem but I need a guide on JDBC serialization. I
would like to put a button on a JSP that will save the result of a query
to local disk as a tab delimited file.
That will permit me to open it in AppleWorks for mailing label printing.
Any pointers greatly appreciated
db=# \h copy
Command: COPY
Description: Copies data between files and tables
Syntax:
COPY [ BINARY ] table [ WITH OIDS ]
FROM { 'filename' | stdin }
[ [USING] DELIMITERS 'delimiter' ]
[ WITH NULL AS 'null string' ]
COPY [ BINARY ] table [ WITH OIDS ]
TO { 'filename' | stdout }
[ [USING] DELIMITERS 'delimiter' ]
[ WITH NULL AS 'null string' ]
db=# copy someTable to '/path/to/file.tsv';
now read tab-separated file file.tsv into the program of your
choice.
or use practical extraction and reporting language to generate
your reports (perl!)...
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] During dump: function not found
oops. Too late to use that option; but thanks! Andrew Gould --- Justin Clift [EMAIL PROTECTED] wrote: Hi Andrew, These functions were indeed created by PgAdmin. It seems to create tables, functions, triggers and views (maybe rules too, not sure) going by the name pgadmin_xxx and pga_xxx I'm pretty sure from looking at PgAdmin 7.1.0 recently it has a menu option to remove it's tables and other constructs from a target database by itself. You might just want to run that instead of doing it yourself/ :-) Regards and best wishes, Justin Clift Andrew Gould wrote: During a pg_dump, I got the following messages: Notice: function pgadmin_get_rows is not dumped. Reason: return type name (oid 87589805) not found. Notice: function pgadmin_get_sequence is not dumped. Reason: return type name (oid 87589772) not found. Does this simply mean that these functions will not be available if I restore from the dump file? Will these messages haunt me down the road in other ways? I'm assuming (dangerous, I know) that these functions were created by PgAdmin rather than being a part of PostgreSQL. I deleted all tables and views named pgadmin* and am trying to weed out everything created by PgAdmin. Thanks, Andrew Gould __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] FTI is really really slow; what am I doing wrong?
Paul C. [EMAIL PROTECTED] writes: Indeed, the cost to look up a single string in the st_fti table is way high: select * from st_fti where string ~ '^kepler'; costs 36703.40, AND its doing a Seq Scan on st_fti, even though an index exists. Have you done a VACUUM ANALYZE on st_fti? Are you running the database in plain C locale? regards, tom lane ---(end of broadcast)--- TIP 3: 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] Re: Syntax for wildcard selection
On Wed, Aug 15, 2001 at 05:11:28PM -0700, Scott Holmes wrote:
It would seem that my database has unseen garbage in the field being queried.
On further testing I find that
select *
from people
where peopcode LIKE 'AB%AH%'
order by peopcode;
works, however
select *
from people
where peopcode LIKE 'AB%AH'
order by peopcode;
does not. I do have nine records that meet the above criteria and are found
if the pattern ends with '%' but not without it.
here's my guess --
you probably used
create table people (
...
peopcode CHAR(...)
...
);
instead of
peopcode VARCHAR(...)
the char type pads with blanks (ascii 32 in latin1 encoding)
to fill the size of the field. varchar truncates the data
only if the data exceeds the field size.
so
like %pat
will match fields ENDING with pat -- for varchar that's
usually at the end of the data; for char, that's at the last few
characters as speficied by the length of the field.
thus, for a field containing
stuff like this
a LIKE %this would not match, but a LIKE %this% would, and so
would LIKE %this .
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] New RPMS ?
On Tuesday 21 August 2001 15:16, Carlos Felipe Zirbes wrote: You alway seemed to me a very reasonable and smart person, but to suggest that just because Fernando Lozano is in Brazil he may not have even a Pentium is, to say the least, a terrible proof of ignorance and prejudice. Whoa. I intended absolutely NO offense with my posting of that comment. I have missionary friends in Brazil, Bolivia, and Peru (amongst other places), and they constantly talk about the slower machines they have to deal with, thus the comment. My sincere apologies for any offense, as none was intended whatsoever. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] FTI is really really slow; what am I doing wrong?
Did you vacuum after populating the tables? If not you should do it On Wed, Aug 22, 2001 at 11:08:55AM -0400, Paul C. wrote: Greetings, I am trying to test out the performance of the contrib/fulltextindex package and I am getting horrid performance results. The Setup: I created a simple table, ST (id SERIAL, body varchar(1024), which is to be searched. I created the ST_FTI table, trigger and indices as per instructions in the FTI readme and C file. To populate the table, I took a flat text version of 'War and Peace' I found on the net, broke it up into sentences and inserted each sentence into ST as a row. So I have about 38,000 sentences and my ST_FTI table is about 2 million rows. The Test: There is exactly one sentence (row) that has the strings 'Newton' and 'Kepler' in it. That is my target. For a straight select on ST: select * from st where body ~* 'newton' and body ~* 'kepler'; the cost is 1100.41 BUT for an query using the FTI indices: select s.* from st s, st_fti f1, st_fti f2 where f1.string ~ '^kepler' and f2.string ~ '^newton' and s.oid = f1.id and s.oid = f2.id; the cost becomes a staggering 80628.92!!! The plans are pasted at the end of this message. Now, I have all the indices created (on id of st_fti, on string of st_fti and on oid of st). I cannot figure out why this is so much worse than the straight query. Indeed, the cost to look up a single string in the st_fti table is way high: select * from st_fti where string ~ '^kepler'; costs 36703.40, AND its doing a Seq Scan on st_fti, even though an index exists. What am I doing wrong? Is it the sheer size of the st_fti table that is causing problems? Any help would be greatly appreciated. Thanks, Paul C. FTI search NOTICE: QUERY PLAN: Merge Join (cost=80046.91..80628.92 rows=110 width=28) - Sort (cost=41827.54..41827.54 rows=19400 width=24) - Hash Join (cost=1992.80..40216.39 rows=19400 width=24) - Seq Scan on st_fti f2 (cost=0.00..36703.40 rows=19400 width=4) - Hash (cost=929.94..929.94 rows=34094 width=20) - Seq Scan on st s (cost=0.00..929.94 rows=34094 width=20) - Sort (cost=38219.37..38219.37 rows=19400 width=4) - Seq Scan on st_fti f1 (cost=0.00..36703.40 rows=19400 width=4) EXPLAIN Plain search: NOTICE: QUERY PLAN: Seq Scan on st (cost=0.00..1100.41 rows=1 width=16) EXPLAIN _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] maximum query length
No. - Original Message - From: jose [EMAIL PROTECTED] To: Postgres [EMAIL PROTECTED] Sent: Wednesday, August 22, 2001 3:51 AM Subject: [GENERAL] maximum query length Hi all, I have a problem related with the maximum query length ERR: query is too long. Maximum length is 16382 I'm using PostgreSQL 6.5.3 and python Is this limit in the newer releases of PostgreSQL too? Thanks for any help Jose Soares ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] During dump: function not found
Andrew Gould writes: Notice: function pgadmin_get_rows is not dumped. Reason: return type name (oid 87589805) not found. Notice: function pgadmin_get_sequence is not dumped. Reason: return type name (oid 87589772) not found. Does this simply mean that these functions will not be available if I restore from the dump file? Yes. Will these messages haunt me down the road in other ways? If something depended on the named functions... What you did was drop the return type of the function (which used to have the shown oid). Therefore the function is already useless anyway. I'm assuming (dangerous, I know) that these functions were created by PgAdmin rather than being a part of PostgreSQL. I deleted all tables and views named pgadmin* and am trying to weed out everything created by PgAdmin. Maybe PgAdmin could provide a drop script for that? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[GENERAL] Re: FTI is really really slow; what am I doing wrong?
I think the problem is that the indexes on the words are not usable for regular expression matching. If the words are folded to lower case when the index is built, then using an exact match (or even like) should be much faster. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Join questions
On Wed, Aug 22, 2001 at 11:54:43AM -0400, Tom Lane [EMAIL PROTECTED] wrote: Bruno Wolff III [EMAIL PROTECTED] writes: I have two related questions about joins. The latter. See http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/explicit-joins.html Thanks, this is what I was looking for. When I looked before I started at the documentation for the select command and didn't think to look in the performance tips area for additional information (though I had been through that area before I didn't remember that it had information about joins that might answer the specific question I thought up this morning). I think it would be useful to have a link from the section on joins under the select command documentation to the information on joins under performance tips, since that extra information gives additional information on the semantics of join commands in addition to actual perfomance tips. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Join questions
Bruno Wolff III [EMAIL PROTECTED] writes: I have two related questions about joins. One is that if you don't group with parenthesis, what order are they done in? Left to right. A JOIN B JOIN C == (A JOIN B) JOIN C. Will the optimizer be able to pick the better order of the two possible orders in the following example or do I need to try both and pick one? The latter. See http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/explicit-joins.html This behavior is not graven on stone tablets (at least not for inner joins), but it was easy to do and is useful for cases where you *don't* want the planner to try all possible join orders. So it'll probably stay like that at least for a release or two, until we have enough field experience to see whether people like it this way or not. regards, tom lane ---(end of broadcast)--- TIP 3: 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
