Re: [GENERAL] Types and SRF's
Your query looks suspiciously complicated... Why not process all 12 months in one shot with something like this : - only one subquery - no join - date between can make an index scan on date select category, sum(amount) as sum_amount, extract (month from date) as month from all_accounts where (date between beginning of the year and end of the year) group by category,month order by category,month ) Not what you wanted but probably massively faster. Or you can do this (in approximate SQL): create type annual_report_type as ( sums numeric(9,2)[12] ); create type my_type as ( month integer, amount numeric ); CREATE AGGREGATE my_sum takes one input which is my_type and sums the amount into the month column of annual_report_type Then : select category, my_sum( my_type(month,amount) as report, extract (month from date) as month from all_accounts where (date between beginning of the year and end of the year) group by category,month order by category,month ) Dunno if this would work, it would be nice I think. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Python Postgresql support?
Use psycopg, it's a hell of a lot faster anyway. On Tue, 31 Aug 2004 23:25:35 -0400, Jerry LeVan <[EMAIL PROTECTED]> wrote: Is it possible to build the python postgresql support library on Mac OSX 10.3.5 with the default python install? Adding "--with-python" gets an error message about libpython not being a shared library when attempting to build postgresql. (pg 7.4.5) Thanks for any pointers. Jerry ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Suppress output from psql?
Checkout http://www.hentzenwerke.com/wp/cron_explained.pdf Look for the MAILTO="" command which you can use to suppress the mailing of cron job output. And try redirecting std output to /dev/null, and/or send the output from psql to a file. John Sidney-Woollett Ron St-Pierre wrote: Is there a way 'within' psql to suppress output? One of our cron scripts calls a sql file which contains various database commands (ALTER TABLEs, UPDATEs, etc) and various user-defined functions. So within this sql file there are various SELECT * FROM myFunction(); which sends output to the user from cron. I can't see anyway to suppress this from the psql docs and I don't believe that I can suppress it from cron either (I'll do some more checking there). Thanks Ron ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Rule/sequence weirdness
Steve Crawford wrote:
I want to monitor inserts to table "foo":
guid: integer not null default nextval('public.guid'::text)
end_time: integer
[snip]
I expected the guid to match. Unfortunately there are no matching
guids between the two tables. It appears that the sequence is being
called twice so the guid in the log table is one greater than the
guid in the main table.
Did I miss something in my rule logic or is this a bug?
Rules are simply macros, so you are right and the sequence will be
accessed twice. You'll want to look at triggers.
--
Richard Huxton
Archonet Ltd
---(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] Exporting/moving Postgress Instance
Nick schrieb: Otherwise is there an recognised dump file in the same way that Oracle has and if so how do I create it? Hi Nick, you should look at pg_dump or pg_dumpall in the docs. (or pg_dump --help) restore the dumped database with psql. Daniel ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] insertiing an image file (blob) into postres...
Dear my friends
I created a column with datatype bytea. The name of
the column is emoicon
I did like this:
kv=# insert into salesreport (salesid, custid,
emoicon) values('13', '4531',
lo_import('/localhome/patrixlinux/arsip/proyek/qt/kv/client/images/1.png'));
ERROR: column "emoicon" is of type bytea but
expression is of type oid
HINT: You will need to rewrite or cast the
expression.
kv=#
but comes error. What is my mistake?
Please tell me
Thank you very much in advance.
__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[GENERAL] Join efficiency
Hello all, Recently a post on this list made me think a bit about the way in which I write my queries. I have always written queries with ordinary joins in this manner: SELECT * FROM a, b WHERE a.x=b.x; However I recently saw an laternative syntax: SELECT * FROM a JOIN b ON a.x=b.x; Is there any difference between these queries in terms of the speed of planning or the quality of the plan untimately used? I'd imagine that the second form provides more information that the planner may be able to use to make a better plan (or make a good plan more easily), but I've never had any problems with the first form. It also seems to me that the second form is more self-documenting, which is something I'm always in favour of. I'd appreciate anyone's thought/insight. Thanks. -- Russell Brown ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Join efficiency
NOTE: The first way cannot support OUTER joins, the second way can. Hence sometimes one has to use the second way for at least some of the joins. PREVIOUSLY: The second way can allow one to tell the planner a "better way" to join the tables. Likewise it can also enable the programmer to force the planner into a worse way. Oops! NOW: I believe that the latest version of postgres (7.4.x) the planner will override the 2nd methods requested join method if it knows of a better way and can do the better way. (Outer joins need to be done last, by the nature of them, and so cannot be changed much, there may be other cases where the planner cannot change the requested plan). I am not an expert, but this is what I recall from following the list. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes [EMAIL PROTECTED] Fax: (416) 441-9085 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Russ Brown > Sent: Wednesday, September 01, 2004 7:55 AM > To: [EMAIL PROTECTED] > Subject: [GENERAL] Join efficiency > > > Hello all, > > Recently a post on this list made me think a bit about the > way in which I > write my queries. > > I have always written queries with ordinary joins in this manner: > > SELECT * FROM a, b WHERE a.x=b.x; > > However I recently saw an laternative syntax: > > SELECT * FROM a JOIN b ON a.x=b.x; > > Is there any difference between these queries in terms of the > speed of > planning or the quality of the plan untimately used? I'd > imagine that the > second form provides more information that the planner may be > able to use > to make a better plan (or make a good plan more easily), but > I've never > had any problems with the first form. > > It also seems to me that the second form is more > self-documenting, which > is something I'm always in favour of. > > I'd appreciate anyone's thought/insight. > > Thanks. > > -- > > Russell Brown > > ---(end of > broadcast)--- > TIP 9: the planner will ignore your desire to choose an index > scan if your > joining column's datatypes do not match > ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Types and SRF's
Thank you for the response Pierre, select category, sum(amount) as sum_amount, extract (month from date) as month from all_accounts where (extract(year from date)=2003) group by category,month order by category,month is certainly much faster than what I am doing but as you pointed out, I want the table to have a column for each month ( and a grand total as the last column). I have not used arrays and aggregates, I will take a look Jerry On Sep 1, 2004, at 3:03 AM, Pierre-Frédéric Caillaud wrote: Your query looks suspiciously complicated... Why not process all 12 months in one shot with something like this : - only one subquery - no join - date between can make an index scan on date select category, sum(amount) as sum_amount, extract (month from date) as month from all_accounts where (date between beginning of the year and end of the year) group by category,month order by category,month ) Not what you wanted but probably massively faster. Or you can do this (in approximate SQL): create type annual_report_type as ( sums numeric(9,2)[12] ); create type my_type as ( month integer, amount numeric ); CREATE AGGREGATE my_sum takes one input which is my_type and sums the amount into the month column of annual_report_type Then : select category, my_sum( my_type(month,amount) as report, extract (month from date) as month from all_accounts where (date between beginning of the year and end of the year) group by category,month order by category,month ) Dunno if this would work, it would be nice I think. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Join efficiency
Russ Brown wrote: I have always written queries with ordinary joins in this manner: SELECT * FROM a, b WHERE a.x=b.x; However I recently saw an laternative syntax: SELECT * FROM a JOIN b ON a.x=b.x; Is there any difference between these queries in terms of the speed of planning or the quality of the plan untimately used? I'd imagine that the second form provides more information that the planner may be able to use to make a better plan (or make a good plan more easily), but I've never had any problems with the first form. The first form allows PG to plan however it sees fit. The second will force the join order to be the same as you specify in the query. This doesn't matter here, but might with a more complicated query. With v7.4 and higher, I believe this join forcing is configurable (join_collapse_limit). It also seems to me that the second form is more self-documenting, which is something I'm always in favour of. I tend to prefer the WHERE form, but that might just be me. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL]
Hi, thanks for your reply, On Wed, 1 Sep 2004 08:10:52 -0400, <[EMAIL PROTECTED]> wrote: NOTE: The first way cannot support OUTER joins, the second way can. Hence sometimes one has to use the second way for at least some of the joins. Yes, I've always done OUTER joins the second way. I suppose it's just the way I was taught SQL: I was initially taught now to do 'ordinary' joins using the first syntax, and then taught 'LEFT' joins using the second syntax when I came to need to use them (I very much leaned SQL 'on the job', though I know of people who *always* use OUTER joins in their queries). I'd never considered that there was another syntax! PREVIOUSLY: The second way can allow one to tell the planner a "better way" to join the tables. Likewise it can also enable the programmer to force the planner into a worse way. Oops! NOW: I believe that the latest version of postgres (7.4.x) the planner will override the 2nd methods requested join method if it knows of a better way and can do the better way. (Outer joins need to be done last, by the nature of them, and so cannot be changed much, there may be other cases where the planner cannot change the requested plan). That being the case, would it be true to say that with recent versions of PostgreSQL they both perform identically, meaning the second could be considered preferable due to its self-documenting nature (and consistency with the OUTER JOIN syntax)? I am not an expert, but this is what I recall from following the list. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes [EMAIL PROTECTED] Fax: (416) 441-9085 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Russ Brown Sent: Wednesday, September 01, 2004 7:55 AM To: [EMAIL PROTECTED] Subject: [GENERAL] Join efficiency Hello all, Recently a post on this list made me think a bit about the way in which I write my queries. I have always written queries with ordinary joins in this manner: SELECT * FROM a, b WHERE a.x=b.x; However I recently saw an laternative syntax: SELECT * FROM a JOIN b ON a.x=b.x; Is there any difference between these queries in terms of the speed of planning or the quality of the plan untimately used? I'd imagine that the second form provides more information that the planner may be able to use to make a better plan (or make a good plan more easily), but I've never had any problems with the first form. It also seems to me that the second form is more self-documenting, which is something I'm always in favour of. I'd appreciate anyone's thought/insight. Thanks. -- Russell Brown ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Russell Brown ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Join efficiency
Does anyone know if there is a postgres shorthand for Oracle's (+) notation to denote an outer join? eg SELECT * from a, b where a.x = b.x (+) John Sidney-Woollett Richard Huxton wrote: Russ Brown wrote: I have always written queries with ordinary joins in this manner: SELECT * FROM a, b WHERE a.x=b.x; However I recently saw an laternative syntax: SELECT * FROM a JOIN b ON a.x=b.x; Is there any difference between these queries in terms of the speed of planning or the quality of the plan untimately used? I'd imagine that the second form provides more information that the planner may be able to use to make a better plan (or make a good plan more easily), but I've never had any problems with the first form. The first form allows PG to plan however it sees fit. The second will force the join order to be the same as you specify in the query. This doesn't matter here, but might with a more complicated query. With v7.4 and higher, I believe this join forcing is configurable (join_collapse_limit). It also seems to me that the second form is more self-documenting, which is something I'm always in favour of. I tend to prefer the WHERE form, but that might just be me. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Join efficiency
John Sidney-Woollett wrote: Does anyone know if there is a postgres shorthand for Oracle's (+) notation to denote an outer join? eg SELECT * from a, b where a.x = b.x (+) Just the standard LEFT JOIN ... afaik -- Richard Huxton Archonet Ltd ---(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 efficiency
Russ Brown wrote: > >> SELECT * FROM a, b WHERE a.x=b.x; > >> SELECT * FROM a JOIN b ON a.x=b.x; > That being the case, would it be true to say that with recent versions of > PostgreSQL they both perform identically, meaning the second could be > considered preferable due to its self-documenting nature (and consistency > with the OUTER JOIN syntax)? Assuming join_collapse_limit is at it's default or set higher... As far as I can say from reading the documentation, following the hackers list and trying out myself: yes, both versions should yield the same optimized query plan and are therefore equal performance wise. You can just use the one you prefer. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] <> syntax legal?
Is it legal syntax to use <> instead of != in a Postgres query? I didn't see it listed on: http://www.postgresql.org/docs/7.4/static/sql-syntax.html but wanted to ask to make sure. -- Greg Donald ---(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] Join efficiency
"Russ Brown" <[EMAIL PROTECTED]> writes: > Is there any difference between these queries in terms of the speed of > planning or the quality of the plan untimately used? http://www.postgresql.org/docs/7.4/static/explicit-joins.html http://www.postgresql.org/docs/7.3/static/explicit-joins.html http://www.postgresql.org/docs/7.2/static/explicit-joins.html http://www.postgresql.org/docs/7.1/static/explicit-joins.html depending on which version you are using. (I think 7.1-7.3 are essentially alike, but 7.4 is not.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] pg_autovacuum (7.4) nss_ldap oddity
I get this in the logs for every database open by pg_autovacuum: Sep 1 14:02:45 cerberus pg_autovacuum: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server This is produced by the bind_to() call in libnss-ldap. This is invoked when /etc/nss_switch.conf specifies ldap; what I don't understand yet is what pg_autovacuum is doing differently from every other application so as to cause this message. Oliver Elphick ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] VISIO and System Tables
Has anyone gotten VISIO setup to see the the pg system tables? I have Visio 2003 and i am not sure of the driver version! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Can't connect to Windows port + other
"Anony Mous" <[EMAIL PROTECTED]> writes: > A few days ago there was a fellow that had trouble connecting remotely to > the 8.0 beta win port. I had the same problem, but have since found the > solution. In postgresql.conf file, ensure the line "listen_addresses" is > set to '*', ie, > > listen_addresses = '*' > > This should do it. Can someone explain to my why this line is here? TCP/IP has always been disabled by default, leaving just Unix sockets for connections. This is probably not a very useful default configuration on Windows. :) -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863 ---(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] Can't connect to Windows port + other
"Anony Mous" <[EMAIL PROTECTED]> writes: > If so, why not set the listen_addresses to '*' right away? Security. It was difficult enough to get people to accept the current liberalized default --- I don't think they'll go for defaulting to -i, which is essentially what you're asking for. It's seen as a good thing that there are two, not one, levels of protection between you and having a database server that's wide open to the entire internet. > but it always fails because I don't know how to add the password for the > super user into the command line, and of course the super user will always > have a password. Is there a way to do this? Create a .pgpass file maybe? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Understanding pg_autovacuum CPU Usage
On Sep 1, 2004, at 5:09 PM, Matthew T. O'Connor wrote: This is the first report I have heard of pg_autovacuum causing cpu usage spikes. When pg_autovacuum wakes up, it loops through all the databases checking for recent activity and decides if it is time to do something. I would think that pg_autovacuum wouldn't use much CPU during this time since it would be waiting a lot on connection startup and query responses from the server. I suppose that it could use a noticeable amount of CPU if you had a lot of databases for it to loop through and a very small connection time. Well, I don't have a lot of databases, but I do have tens of thousands of tables, many of which have hundreds of thousands of rows. I don't know if that plays into things. Are you using pooled connections? No. Also is this 7.4.x or 8.0 beta? Oops. Sorry. It's 7.4.5, specifically. Can you hook up a debugger and see what it's doing during the CPU spikes? That's going to be a little tricky because it's a production environment. So far, the spikes haven't hurt too much because they don't last very long. I'll see if I can get anything similar to occur in our development environment. -tfo ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Can't connect to Windows port + other
On Wed, 2004-09-01 at 16:12, Doug McNaught wrote: > "Anony Mous" <[EMAIL PROTECTED]> writes: > > > A few days ago there was a fellow that had trouble connecting remotely to > > the 8.0 beta win port. I had the same problem, but have since found the > > solution. In postgresql.conf file, ensure the line "listen_addresses" is > > set to '*', ie, > > > > listen_addresses = '*' > > > > This should do it. Can someone explain to my why this line is here? > > TCP/IP has always been disabled by default, leaving just Unix sockets > for connections. This is probably not a very useful default > configuration on Windows. :) > > -Doug Heh, at least it makes the user learn how to configure their postgresql configuration. ;-) -Robby -- /*** * Robby Russell | Owner.Developer.Geek * PLANET ARGON | www.planetargon.com * Portland, OR | [EMAIL PROTECTED] * 503.351.4730 | blog.planetargon.com * PHP/PostgreSQL Hosting & Development / signature.asc Description: This is a digitally signed message part
Re: [GENERAL] Can't connect to Windows port + other
Great, I found the part of the docs referring to this (ch 27.11) however, it refers to creating this file in the user's home directory. It seems this part of the documentation is assuming I'm using *nix. In Windows, where should this file be located? Also, .pgpass is an invalid file name in Win. Thanks! -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: September 1, 2004 5:19 PM To: Anony Mous Cc: [EMAIL PROTECTED] Subject: Re: [GENERAL] Can't connect to Windows port + other "Anony Mous" <[EMAIL PROTECTED]> writes: > If so, why not set the listen_addresses to '*' right away? Security. It was difficult enough to get people to accept the current liberalized default --- I don't think they'll go for defaulting to -i, which is essentially what you're asking for. It's seen as a good thing that there are two, not one, levels of protection between you and having a database server that's wide open to the entire internet. > but it always fails because I don't know how to add the password for the > super user into the command line, and of course the super user will always > have a password. Is there a way to do this? Create a .pgpass file maybe? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Not able to build libpq for Windows
OK, I see your problem is the compilation of psql, which I am not sure has been tested yet. I saw a few problems: libpq bcc linked path.c while it was not needed psql bcc and vc linked in path.c but didn't create a pg_config_paths.h with the proper values. The pg_config_paths.h in libpq is not the same as the one in psql. This fixes that. Please test and let me know if it doesn't work. Patch attached and applied. --- Vidyasagara Guntaka wrote: > Hi Bruce, > I'm still getting some compilation errors. I'm listing the steps I followed below: > 1. Downloaded the postgresql-8.0.0beta2 file > 2. Unzipped it. > 3. Change directory to src directory and issued "nmake /f win32.mak" command. > > I see many undelcared identifiers in port/path.c file. Looks like they are > environment setup related variables. Do I need to do any configuration before > starting the compilation using nmake? > > Here I'm reproducing the compilation results : > > __ > C:\temp\postgresql-8.0.0beta2\src>nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cd include > if not exist pg_config.h copy pg_config.h.win32 pg_config.h > cd .. > cd interfaces\libpq > nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > Building the Win32 static library... > > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nma02964. > getaddrinfo.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmb02964. > pgstrcasecmp.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmc02964. > thread.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmd02964. > inet_aton.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nme02964. > crypt.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmf02964. > noblock.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmg02964. > dllist.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmh02964. > md5.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmi02964. > ip.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmj02964. > wchar.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmk02964. > encnames.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nml02964. > win32.c > fe-auth.c > fe-protocol2.c > fe-protocol3.c > fe-connect.c > fe-exec.c > fe-lobj.c > fe-misc.c > fe-print.c > fe-secure.c > pqexpbuffer.c > pthread-win32.c > link.exe -lib @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmm02964. > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmn02964. > libpqdll.c > rc.exe /l 0x409 /fo".\Release\libpq.res" libpq.rc > link.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmo02964. >Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp > cd ..\..\bin\psql > nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nma02896. > sprompt.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmb02896. > getopt.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmc02896. > getopt_long.c > cl.exe @C:\DOCUME~1\vguntaka\LOCALS~1\Temp\nmd02896. > path.c > ..\..\port\path.c(198) : error C2065: 'PGBINDIR' : undeclared identifier > ..\..\port\path.c(198) : warning C4047: 'function' : 'const char *' differs in > levels of indirection from 'int ' > ..\..\port\path.c(198) : warning C4024: 'relative_path' : different types for formal > and actual parameter 1 > ..\..\port\path.c(198) : error C2065: 'PGSHAREDIR' : undeclared identifier > ..\..\port\path.c(198) : warning C4047: 'function' : 'const char *' differs in > levels of indirection from 'int ' > ..\..\port\path.c(198) : warning C4024: 'relative_path' : different types for formal > and actual parameter 2 > ..\..\port\path.c(201) : warning C4047: 'function' : 'const char *' differs in > levels of indirection from 'int ' > ..\..\port\path.c(201) : warning C4024: 'strncpy' : different types for formal and > actual parameter 2 > ..\..\port\path.c(215) : warning C4047: 'function' : 'const char *' differs in > levels of indirection from 'int ' > ..\..\port\path.c(215) : warning C4024: 'relative_path' : different types for formal > and actual parameter 1 > ..\..\port\path.c(232) : warning C4047: 'function' : 'const char *' differs in > levels of indirection from 'int ' > ..\..\port\path.c(232) : warning C4024: 'relative_path' : different types for formal > and actual parameter 1 > ..\..\port\path.c(232) : error C2065: 'INCLUDEDIR' : undeclared identifier > ..\..\port\path.c(232) : warning C4047: 'function' : 'const char *' differs in > levels of in
Re: [GENERAL] can't build libpq with beta 2
Wow, I have no idea why that is failing. I just fixed some VC problems for someone but they were actual bugs related to path.c. Your failure looks like a build tools problem. --- Dann Corbit wrote: > U:\postgresql-8.0.0beta2\src\interfaces\libpq>nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 8.00.40607.16 > Copyright (C) Microsoft Corporation. All rights reserved. > > Building the Win32 static library... > > cl.exe @u:\tmp\nm33D2.tmp > cl : Command line warning D9002 : ignoring unknown option '/YX' > cl : Command line warning D9035 : option 'GX' has been deprecated and > will be removed in a future release > cl : Command line warning D9036 : use 'EHsc' instead of 'GX' > getaddrinfo.c > ..\..\include\c.h(66) : fatal error C1083: Cannot open include file: > 'strings.h': No such file or directory > NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' > Stop. > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[GENERAL] The future of built-in geometric data types
I'm pretty clueless in regard to the PostGIS situation. Will it be integrated with PostgreSQL in the future? What are the benefits of using the builtin geometry types (since they don't have R-tree indexes)? -- dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Understanding pg_autovacuum CPU Usage
Thomas F.O'Connell wrote: Well, I don't have a lot of databases, but I do have tens of thousands of tables, many of which have hundreds of thousands of rows. I don't know if that plays into things. Number of rows is irrelevant, but the number of tables might not be. It could be that the process of checking it's list of tables against the server might be slow when used with lots of tables. Does this cpu spike happen every other loop? If so then that is the culprit. Editing pg_autovacuum.c and changing: #define UPDATE_INTERVAL 2 to some higher value. The default UPDATE_INTERVAL tells pg_autovacuum to check for added / removed tables every 2 loops. Oops. Sorry. It's 7.4.5, specifically. Ok Can you hook up a debugger and see what it's doing during the CPU spikes? That's going to be a little tricky because it's a production environment. So far, the spikes haven't hurt too much because they don't last very long. I'll see if I can get anything similar to occur in our development environment. Try the simple recompile with the larger update interval first and see if that's the problem. Matthew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Can't connect to Windows port + other
Anony Mous wrote: Great, I found the part of the docs referring to this (ch 27.11) however, it refers to creating this file in the user's home directory. It seems this part of the documentation is assuming I'm using *nix. In Windows, where should this file be located? Also, .pgpass is an invalid file name in Win. What is invalid about it? Windows explorer tried to be cute and doesn't allow you to create it, but that doesn't stop you from creating it with another program. Also, windows has users home directories, so the .pgpass file would go there, perhaps: C:\Documents and Setting\postgres\.pgpass Matthew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] The future of built-in geometric data types
David Garamond <[EMAIL PROTECTED]> writes: > I'm pretty clueless in regard to the PostGIS situation. Will it be > integrated with PostgreSQL in the future? No. Wrong license. > What are the benefits of using > the builtin geometry types (since they don't have R-tree indexes)? Some of 'em do. By and large, though, they are more proof-of-concept than industrial-strength code, IMHO. PostGIS is certainly a better bet if it does what you want. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Understanding pg_autovacuum CPU Usage
On Sep 1, 2004, at 10:27 PM, Matthew T. O'Connor wrote: Number of rows is irrelevant, but the number of tables might not be. It could be that the process of checking it's list of tables against the server might be slow when used with lots of tables. Does this cpu spike happen every other loop? Is there an easy way to determine if it's happening every other loop? Try the simple recompile with the larger update interval first and see if that's the problem. How difficult would it be to make this a command-line argument if it turns out to be a run-time issue? Thanks for the input. -tfo ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] The future of built-in geometric data types
On Wed, Sep 01, 2004 at 11:52:05PM -0400, Tom Lane wrote: > David Garamond <[EMAIL PROTECTED]> writes: > > I'm pretty clueless in regard to the PostGIS situation. Will it be > > integrated with PostgreSQL in the future? > > No. Wrong license. If the license were changed to be BSD compatible, are there other barriers to adoption? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
