Re: [HACKERS] allowed user/db variables
> I was considering adding this and the stuff Andreas requested to > pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's > important to kept them consistent with pg_settings). Were the Red Hat > guys going to do this? pg_settings would be fine for phpPgAdmin. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Physical Database Configuration
> Well, correct solution is to implement tablespaces on which objects like > databases, tables and indexes can be put. I have started working on tablespaces (to the extent that I am capable!), based not on the rejected patch, but on Jim's eventual syntax proposal that was never developed. eg. CREATE LOCATION blah AS '/exports/indexes' CREATE DATABASE db WITH LOCATION loc; CREAT TABLE foo (a PRIMARY KEY LOCATION blah) LOCATION blah; ..etc... > There was a long discussion on this and there was a tablespaces patch. It was > agreed that tablespace as a set of directories would be a good point to start. If anyone wants to help me (as I've not had time to code on it for a while due to phpPgAdmin), then they can email me! I'm working from a top-down perspective - eg. adding new catalog and grammar and support functions before mucking about with low level storage... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] allowed user/db variables
Christopher Kings-Lynne wrote: See my followup. Which bits of info would you like to see added that SHOW doesn't reveal? Unlike andreas, I'm not interested in the types and ranges of values, what I need to know is the GUC variables that the user is allowed to set, in particular what they can ALTER USER / SET ... so that I can display that feature... I was considering adding this and the stuff Andreas requested to pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's important to kept them consistent with pg_settings). Were the Red Hat guys going to do this? Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
On 24 Jun 2003 at 14:48, Jonathan Bartlett wrote: > I know the current method for specifying alternate drives for PG tables is > by using symlinks. I had some ideas for simple ways to do this in PG > code, but wanted to know if anyone was working on this right now. I'd > hate to take the time to start messing with this if others were already on > it. Well, correct solution is to implement tablespaces on which objects like databases, tables and indexes can be put. There was a long discussion on this and there was a tablespaces patch. It was agreed that tablespace as a set of directories would be a good point to start. I have no idea what is the status of that effort right now. You can search the archives or I hope this kicks a fresh discussion..:-) Please correct me if I am wrong. I am quoting from off my head.. not a trusted source.. Bye Shridhar -- Harriet's Dining Observation: In every restaurant, the hardness of the butter patsincreases in direct proportion to the softness of the bread. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Jan Wieck wrote: > The Hermit Hacker wrote: > > On Tue, 24 Jun 2003, Bruce Momjian wrote: > > > >> The Hermit Hacker wrote: > >> > On Tue, 24 Jun 2003, Dann Corbit wrote: > >> > > >> > > I did something about it. I raised the issue. > >> > > Is it really so that whoever it is that raises a question is also the > >> > > one who must fix the issue raised? > >> > > A strange model indeed. > >> > > >> > Its worked for us ... > >> > > >> > Wait, I know what should make you happy ... it won't get anytihng done, > >> > but ... > >> > > >> > Bruce, can you add "* Improve Testing" to the TODO list > >> > >> That seems too vague for TODO. We might as well add "Make PostgreSQL > >> faster". :-) > > > > 'K, can you add that one too? :) > > Make his life easier: > > Replace the entire TODO with "Make PostgreSQL better" > > That pretty much summs it up, no? Oh, I like that ... definitely leaves it open to the interpretation of the reader as to what would make it better :) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: > On Tue, 24 Jun 2003, Dann Corbit wrote: > > > I did something about it. I raised the issue. > > Is it really so that whoever it is that raises a question is also the > > one who must fix the issue raised? > > A strange model indeed. > > Its worked for us ... > > Wait, I know what should make you happy ... it won't get anytihng done, > but ... > > Bruce, can you add "* Improve Testing" to the TODO list That seems too vague for TODO. We might as well add "Make PostgreSQL faster". :-) 'K, can you add that one too? :) Make his life easier: Replace the entire TODO with "Make PostgreSQL better" That pretty much summs it up, no? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] libpgtcl and pgtclsh
I'm looking to move both of these over to GBorg, like we did with the C++ interfaces and ODBC ... the problem is, unlike those, I can't find anyone that is actually working with it ... Is anyone using these? Anyone willing to step up and act as maintainer for it? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Sorry Marc, but that ain't entirely true. There have been a good number of examples where the one who raised an issue isn't just of the format to implement it. So someone else jumped in and did it instead. I don't need to pick any particular samples, you know that it happened a few times. And don't get the wrong picture. Yes, Dann is "just talking" here on the testing methodology front. But as much as it looks like we two hate each other on this thread, we actually start working together on a totally different issue. And to say the least, I like his version better than Katie's ... 'nuff said. Jan Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add "* Improve Testing" to the TODO list > Someone has to spearhead it > ... you seem to be passionate about seeing it happen, but > don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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: [HACKERS] PHP/PgSQL *and* libpq ...
Added to TODO: * Allow creation of a libpq-only tarball --- The Hermit Hacker wrote: > > Just a side bar to the whole thread about PHP/MySQL ... I realize that > libpq is intwined with the backend right now, but if anyone could think of > a way of at least adding a make target that would create a libpq.tar.gz > distribution, I believe it would go a long way towards making it easier > for ppl to add/compile in PgSQL support into PHP ... right now, to do so, > you have to download an 8Meg file to get libpq ... if it could be reduced > to a <.5Meg tar.gz file: > > svr1# du -sk libpq > 532 libpq > > it would be less onerous to download and add the support in ... > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PHP/PgSQL *and* libpq ...
Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a <.5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] compile warnings
Joe Conway wrote: > Since we're getting close to a freeze, I thought I'd point out these > warnings again: > > make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' > [...] > i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes > -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include > -I../../../../src/include/utils -I../../../../src/include > -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD > timestamp.c: In function `dttofmtasc_replace': > timestamp.c:468: warning: `%g' yields only last 2 digits of year > timestamp.c:606: warning: `%x' yields only last 2 digits of year in some > locales Micheal Meskes has asked if anyone has an idea on how to fix this. > -and- > > make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' > [...] > i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes > -Wmissing-declarations -Wno-error -I./../include -I. > -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 > -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/include\" -c -o > preproc.o preproc.c -MMD > In file included from preproc.y:6189: > pgc.c: In function `yylex': > pgc.c:1386: warning: label `find_rule' defined but not used > /usr/include/ctype.h: At top level: > pgc.c:3377: warning: `yy_flex_realloc' defined but not used > > Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 > systems. I believe these are coming from bison and it is difficult to fix. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] compile warnings
Since we're getting close to a freeze, I thought I'd point out these warnings again: make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:468: warning: `%g' yields only last 2 digits of year timestamp.c:606: warning: `%x' yields only last 2 digits of year in some locales -and- make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I./../include -I. -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/include\" -c -o preproc.o preproc.c -MMD In file included from preproc.y:6189: pgc.c: In function `yylex': pgc.c:1386: warning: label `find_rule' defined but not used /usr/include/ctype.h: At top level: pgc.c:3377: warning: `yy_flex_realloc' defined but not used Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 systems. Joe ---(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: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: > > > Don't care and won't do are not the same thing. > > > > Well, actually, they are ... if someone doesn't care, they > > aren't going to do, are they? > > You have had the time to do everything you ever cared about? No no, that isn't what he is arguing (or I'm miss reading) ... he said that "not caring about something *and* not doing it aren't the same thing" ... which isnt' the same as caring but not having the time ... is it? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Bruce Momjian wrote: > The Hermit Hacker wrote: > > On Tue, 24 Jun 2003, Dann Corbit wrote: > > > > > I did something about it. I raised the issue. > > > Is it really so that whoever it is that raises a question is also the > > > one who must fix the issue raised? > > > A strange model indeed. > > > > Its worked for us ... > > > > Wait, I know what should make you happy ... it won't get anytihng done, > > but ... > > > > Bruce, can you add "* Improve Testing" to the TODO list > > That seems too vague for TODO. We might as well add "Make PostgreSQL > faster". :-) 'K, can you add that one too? :) ---(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: [HACKERS] Two weeks to feature freeze
I think it was a useful discussion. I find it interesting to compare our clearly ad-hock testing methods to traditional commercial testing strategies. I think our results are very good, but it does look awful "ad-hock" and it is easy to see how someone would question its effectiveness. Of course, the whole open source development model seems ad-hock too, and on the surface seems inferior to a commercial software development model, but there again, the proof is in the result. --- Dann Corbit wrote: > > -Original Message- > > From: The Hermit Hacker [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2003 6:10 PM > > To: Dann Corbit > > Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce > > Momjian; Tom Lane; Jason Earl; PostgreSQL-development > > Subject: RE: [HACKERS] Two weeks to feature freeze > > > > > > On Tue, 24 Jun 2003, Dann Corbit wrote: > > > > > I did something about it. I raised the issue. > > > Is it really so that whoever it is that raises a question > > is also the > > > one who must fix the issue raised? A strange model indeed. > > > > Its worked for us ... > > > > Wait, I know what should make you happy ... it won't get > > anytihng done, but ... > > > > Bruce, can you add "* Improve Testing" to the TODO list > > It is surely a titanic mistake to bring up any issue on this list if you > do not plan to fix it yourself. > > > > > Someone has to spearhead it > > > > ... you seem to be passionate about seeing it happen, but > > don't care > > > > enough to do anything about it ... > > > > > > Don't care and won't do are not the same thing. > > > > Well, actually, they are ... if someone doesn't care, they > > aren't going to do, are they? > > You have had the time to do everything you ever cared about? > > It is really true that I have made a titanic waste of time in an effort > to get someone else to do something about it or at least get them > interested in it. I won't waste my time in that way again. I deeply > rue the time I have wasted already. > > -- 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 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: [HACKERS] Two weeks to feature freeze
> -Original Message- > From: The Hermit Hacker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 6:10 PM > To: Dann Corbit > Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce > Momjian; Tom Lane; Jason Earl; PostgreSQL-development > Subject: RE: [HACKERS] Two weeks to feature freeze > > > On Tue, 24 Jun 2003, Dann Corbit wrote: > > > I did something about it. I raised the issue. > > Is it really so that whoever it is that raises a question > is also the > > one who must fix the issue raised? A strange model indeed. > > Its worked for us ... > > Wait, I know what should make you happy ... it won't get > anytihng done, but ... > > Bruce, can you add "* Improve Testing" to the TODO list It is surely a titanic mistake to bring up any issue on this list if you do not plan to fix it yourself. > > > Someone has to spearhead it > > > ... you seem to be passionate about seeing it happen, but > don't care > > > enough to do anything about it ... > > > > Don't care and won't do are not the same thing. > > Well, actually, they are ... if someone doesn't care, they > aren't going to do, are they? You have had the time to do everything you ever cared about? It is really true that I have made a titanic waste of time in an effort to get someone else to do something about it or at least get them interested in it. I won't waste my time in that way again. I deeply rue the time I have wasted already. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: > On Tue, 24 Jun 2003, Dann Corbit wrote: > > > I did something about it. I raised the issue. > > Is it really so that whoever it is that raises a question is also the > > one who must fix the issue raised? > > A strange model indeed. > > Its worked for us ... > > Wait, I know what should make you happy ... it won't get anytihng done, > but ... > > Bruce, can you add "* Improve Testing" to the TODO list That seems too vague for TODO. We might as well add "Make PostgreSQL faster". :-) -- 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 8: explain analyze is your friend
Re: [HACKERS] compile failure on cvs tip --with-krb5
Patch applied. Thanks. --- Kurt Roeckx wrote: > On Fri, Jun 20, 2003 at 07:48:02PM -0700, Joe Conway wrote: > > This change (I'm sure this will wrap poorly -- sorry): > > http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85&r2=1.86 > > > > modified SockAddr, but no corresponding change was made here > > (fe-auth.c:612): > > > > case AUTH_REQ_KRB5: > > #ifdef KRB5 > > if (pg_krb5_sendauth(PQerrormsg, conn->sock, &conn->laddr.in, > >&conn->raddr.in, > >hostname) != STATUS_OK) > > > > It's not obvious to me what the change ought to be though. > > This patch should hopefully fix both kerberos 4 and 5. > > > Kurt > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html -- 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 8: explain analyze is your friend
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
Patch applied. Thanks. --- Michael A Nachbaur wrote: > Attached is a patch that provides *VERY* limited support for multiple slave > servers. I haven't tested it very well, so use at your own risk (and I > recommend against using it in production). > > Basically, I have a central database server that has 4 summary tables inside > it replicated to a remote slave (these database tables are for my mail server > authentication, so these are replicated to another server tuned for many > connections, and so I don't have postgres connections opened straight to my > back-end database server). > > Unfortunately, I also wanted to implement a replication database server for > hot-backups. I realized, too late, that the replication process is pretty > greedy and will try to replicate all tables marked as a "MasterAddTable". > > To make a long story, I made a patch to RServ.pm and Replicate that allows you > to specify, on the command line, a list of tables that you want to > replicate...it'll ignore all others. > > I haven't finished, since this has to be integrated with CleanLog for > instance, but this should (and does) suffice for the moment. > > I have yet to test it with two slaves, but at least my mail server replication > database now works (it was failing every time it tried to replicate, for a > variety of reasons). > > Anyone have any suggestions on how to improve on this? (or, if someone more > familiar with this code wants to take the ball and run with it, you're > welcome to). > > -- > Michael A Nachbaur <[EMAIL PROTECTED]> [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: > I did something about it. I raised the issue. > Is it really so that whoever it is that raises a question is also the > one who must fix the issue raised? > A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add "* Improve Testing" to the TODO list > > Someone has to spearhead it > > ... you seem to be passionate about seeing it happen, but > > don't care enough to do anything about it ... > > Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
> -Original Message- > From: The Hermit Hacker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 5:26 PM > To: Dann Corbit > Cc: Jan Wieck; scott.marlowe; Bruce Momjian; Tom Lane; Jason > Earl; PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > On Mon, 23 Jun 2003, Dann Corbit wrote: > > > > -Original Message- > > > From: Jan Wieck [mailto:[EMAIL PROTECTED] > > > Sent: Monday, June 23, 2003 10:30 PM > > > To: Dann Corbit > > > Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; > > > PostgreSQL-development > > > Subject: Re: [HACKERS] Two weeks to feature freeze > > [snip] > > > I personally think you don't actually ever did any > software testing > > > yourself. You are not really talking from experience, are you? So > > > please, show me what you have now, or get one more plus on my > > > minus-list. > > > > I have already posted enough information to show my qualitications. > > > > Whether I am qualified or not is irrelevant to whether the argument > > has merit or not. > > > > I have raised what I consider to be an important issue. > > You have raised a point that you are not prepared to do > anything about though I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. > ... nobody disagrees with you about > adding more testing, Actually some do, but that's neither here nor there. > but if you aren't willing to do the > work, why should anyone else be? Perhaps they have the time and care about the result. > Someone has to spearhead it > ... you seem to be passionate about seeing it happen, but > don't care enough to do anything about it ... Don't care and won't do are not the same thing. ---(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: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Robert Treat wrote: > On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote: > > On Mon, 23 Jun 2003, Robert Treat wrote: > > > > > > The target-date-based approach we've taken in the last couple of > > > > releases seems much more productive. > > > > > > > > > > productive on a small scale; for sure. productive for large scale > > > features... well, that's why it's being discussed. > > > > 'K, but if we extend the dev cycle in order to get 'foo' in, how is that > > better then having 'foo' continue to be developed thru the release and > > committed in the next cycle? > > > > I think it makes it easier to code 'foo' since you're not coding against > (quite as much of) a moving target. I *soo* disagree with this one ... the only way that postgresql is going to stop being a moving target so that someone can code 'foo' is if everyone else goes to sleep until that happens ... > It could also help people plan better since they would know that foo is > coming in the next release. 'K, that helps the end users, but that doesn't do anything for the person developing 'foo' ... > i'm sure everyone who doesn't want foo would agree with that position. > The counter though is those folks who did want foo but now have to wait > 4-6 months for the next release since foo took a month longer to develop > than was initially planned. Ya, but, based on past experience (hell, this release has been a good example) ... you delay the release because developer of 'foo' figures "oh, it will be ready in another month", and then something comes up that causes that "commitment" not to happen, so we delay it "yet another month"? And I'm not saying that the second delay was due to mis-estimating the time needed ... suddenly getting really busy on a contract, a day job, a death in the family, etc ... you cannot predict what could cause a delay, or how long such a delay would take ... > the whole discussion is based on how do we get big projects done when no > one is motivated to work on 'foo' until there faced with a deadline; > this idea puts the pressure on 'foo' developers from the get go. i'm not > saying this a guaranteed way to solve that problem but i think it is a > possible solution. i'm sure there will be big projects most people don't > care about (win32) and big projects most people would like (replication) > so the amount of like or dislike of the idea would be relative in > practice, the key question is would this actually motivate folks more to > get big projects finished faster? since there are only a handful of > folks who fall into that category they can decide for themselves, and if > it wouldn't motivate them, then the question can be asked again, what > would? First, we already seen that such a 'pressure' doesn't matter, especially if when push comes to shove, they know we'll postpone to accommodate them ... Second ... I don't believe the problem *is* the release cycles ... I think the problem that needs a solution is how to "open up" these large projects so that the deadline(s) don't fall on ones person's shoulders to get done .. how do we encourage/promote "work groups" for the large projects? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: > > Would it be nice if we had more tests? Yes. In fact, one of > > the items on my > > personal todo list is to devise a more versatile performance > > test than > > pgbench for testing postgresql parameters, builds, and > > installations. But > > it's not getting done by me carping at people on the Hackers > > list. It'll get > > done when I spend a long weekend writing Perl. > > > > Put up or shut up time, Dann. > > It's shut up, then. I'm not willing to commit to this effort. Woo hoo ... now *that* was the longest, useless thread I think we've had here so far .. we almost need to start a 'hall of shameful threads' ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: > > -Original Message- > > From: Jan Wieck [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 10:30 PM > > To: Dann Corbit > > Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; > > PostgreSQL-development > > Subject: Re: [HACKERS] Two weeks to feature freeze > [snip] > > I personally think you don't actually ever did any software testing > > yourself. You are not really talking from experience, are you? So > > please, show me what you have now, or get one more plus on my > > minus-list. > > I have already posted enough information to show my qualitications. > > Whether I am qualified or not is irrelevant to whether the argument has > merit or not. > > I have raised what I consider to be an important issue. You have raised a point that you are not prepared to do anything about though ... nobody disagrees with you about adding more testing, but if you aren't willing to do the work, why should anyone else be? Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
'K, and do you have any ETA on when you'll have this translated into some useful tests that we can incorporate? On Mon, 23 Jun 2003, Dann Corbit wrote: > Here is a list of a small sample of the citations available from the ACM > on software testing: > > http://portal.acm.org/citation.cfm?id=581358&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=376180&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=367020&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=308790&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=257668&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=248262&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > http://portal.acm.org/citation.cfm?id=227759&coll=portal&dl=ACM&CFID=657 > 0092&CFTOKEN=81653602 > > These articles are careful, scientific studies that have been > extensively peer reviewed. > > These articles indicate that testing is a good idea. > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_get_triggerdef in pg_dump
Bruce Momjian wrote: I don't think an option to do such justification would be good unless we can do it consistenly in the code, and there is enough demand. It's no big additional effort to do this, and going back and forth is not a big problem. I wouldn't invent an option for that, just do it. Let's see what's happening. At least, there seems agreement on not using tabs but spaces. Still, I'd like to have somebody having a look at my algorithm. It's the key component, which should be proven right theoretically. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] capturing and storing query statement with
--On Tuesday, June 24, 2003 14:07:23 -0700 Joe Conway <[EMAIL PROTECTED]> wrote: (moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Comments? I was thinking the same thing. Currently I use the contrib/dblink supplied function, but a firstclass, in the default install, version would be nice. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Robert Treat wrote: > the whole discussion is based on how do we get big projects done when no > one is motivated to work on 'foo' until there faced with a deadline; > this idea puts the pressure on 'foo' developers from the get go. i'm not > saying this a guaranteed way to solve that problem but i think it is a > possible solution. i'm sure there will be big projects most people don't > care about (win32) and big projects most people would like (replication) > so the amount of like or dislike of the idea would be relative in > practice, the key question is would this actually motivate folks more to > get big projects finished faster? since there are only a handful of > folks who fall into that category they can decide for themselves, and if > it wouldn't motivate them, then the question can be asked again, what > would? I can confirm that there are several people working on Win32/PITR right now, maybe four, that wouldn't if we hadn't set the beta freeze at July 1 --- so such pressure is a real motivator --- though certainly this isn't the way we want to motivate developers. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 14:43:24 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: TODO updated: * Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle I just posted a patch to -patches for this. (it's a quickie, even). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] capturing and storing query statement with rules
(moving to HACKERS) Mike Mascari wrote: Joe Conway wrote: I think this shows how to do what you want: http://archives.postgresql.org/pgsql-sql/2003-05/msg00301.php Maybe debug_query_string should be mapped into a variable like CURRENT_USER? Perhaps something like CURRENT_QUERY? I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Comments? Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote:
> On Mon, 23 Jun 2003, Robert Treat wrote:
>
> > > The target-date-based approach we've taken in the last couple of
> > > releases seems much more productive.
> > >
> >
> > productive on a small scale; for sure. productive for large scale
> > features... well, that's why it's being discussed.
>
> 'K, but if we extend the dev cycle in order to get 'foo' in, how is that
> better then having 'foo' continue to be developed thru the release and
> committed in the next cycle?
>
I think it makes it easier to code 'foo' since you're not coding against
(quite as much of) a moving target. I could also help developers stay
focused on particular projects since they are the "hot potato" for a
given release. It could also help people plan better since they would
know that foo is coming in the next release.
> If it takes foo 6 months to develop, I'd rather have the release happen
> after 4 months as per normal (or close to it) and have 'foo' brought in
> part way into dev cycle 2 ... at least then, if 'foo' ends up taking 7
> months, we aren't delaying even further ...
>
i'm sure everyone who doesn't want foo would agree with that position.
The counter though is those folks who did want foo but now have to wait
4-6 months for the next release since foo took a month longer to develop
than was initially planned.
> Its not like our dev cycles have 'idle periods' where nothing is happening
> and we're waiting for a feature to come along ... there is *alot* of
> changes going on that affect alot of ppl that don't really care about
> feature 'foo' coming along ...
>
this doesn't really change anything for those folks, since the only
rational is "every 6 months we do a release." ie. there are *alot* of
changes going on that affect alot of ppl that don't really care about
waiting n more months...
the whole discussion is based on how do we get big projects done when no
one is motivated to work on 'foo' until there faced with a deadline;
this idea puts the pressure on 'foo' developers from the get go. i'm not
saying this a guaranteed way to solve that problem but i think it is a
possible solution. i'm sure there will be big projects most people don't
care about (win32) and big projects most people would like (replication)
so the amount of like or dislike of the idea would be relative in
practice, the key question is would this actually motivate folks more to
get big projects finished faster? since there are only a handful of
folks who fall into that category they can decide for themselves, and if
it wouldn't motivate them, then the question can be asked again, what
would?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ss_family in hba.c
Bruce, On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote: > Kurt Roeckx wrote: > > All that probably needed to change for cygwin was to no longer > > use sa_family_t in the getaddrinfo.c. > > But Jason reported he needed that typedef for sa_family_t. Jason, is > that accurate. Yes. > If you remove the Cygwin typedef in pqcomm.h, does the compile fail? Yes: gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DBUILDING_DLL -c -o printtup.o printtup.c In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:54: parse error before "sa_family_t" [snip] Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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: [HACKERS] pg_get_triggerdef in pg_dump
> SELECT foo > FROM bar b > LEFT JOIN chair c USING (thekeycol) > WHERE ... > :-) Sub-selects are much nicer: SELECT foo , bar , (SELECT anotherfoo FROM tab2 WHERE tab2.col = tab1.col) FROM tab JOIN yet_another_table AS yat ON (yat.c = tab.c) LEFT JOIN tab1 USING (anothercol) WHERE stuff IS TRUE AND ( optional IS NULL OR optional > 5) HAVING count(*) > (SELECT total FROM total_table) ORDER BY foo GROUP BY foo , bar , 3; -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] ss_family in hba.c
Kurt Roeckx wrote: > On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote: > > > > I have applied a patch to CVS to fix the problem. It is all your patch, > > except for the part you got from me, which was wrong. :-( > > > > It took me a while to realize the subtlety of your patch. First, it > > removes the use of sa_family_t _except_ for cases that don't have > > SOCKADDR_STORAGE, where it is required. Second, it allows for a > > structure member named ss_family or __ss_family, tested via configure. > > > > This should fix most platforms. I am not sure how cygwin is going to > > handle this --- we might have to add a specific sa_family_t typedef for > > that platform --- MinGW does have sa_family_t, but probably doesn't need > > it anyway. Testing for the size of sa_family_t is possible via > > configure, but if only cygwin needs it, we can just hard-code that > > platform in the template files. Cygwin folks, would you test CVS and > > let me know. > > There are probably other systems that don't have sa_family_t yet, > but they should be rather old. Even my Solaris 2.6 already seems > to have it. > > What I was confused about is, is that cygwin seems to have a > struct sockaddr_storage in the first place (in winsock2.h). I'm > not sure what problem he really had since he only told it how he > solved it. > > All that probably needed to change for cygwin was to no longer > use sa_family_t in the getaddrinfo.c. But Jason reported he needed that typedef for sa_family_t. Jason, is that accurate. If you remove the Cygwin typedef in pqcomm.h, does the compile fail? -- 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 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: [HACKERS] pg_get_triggerdef in pg_dump
I don't think an option to do such justification would be good unless we can do it consistenly in the code, and there is enough demand. --- Andreas Pflug wrote: > Rod Taylor wrote: > > >>Oh, one more thing --- right justify isn't as accepted as left-justify > >> > >> > > > >But it looks so much better... > > > > > Ye! > Consider this: > > SELECT foo > FROM bar b > LEFT JOIN chair c USING (thekeycol) > WHERE ... > :-) > > versus > > SELECT foo > FROM bar b > LEFT JOIN chair c USING (thekeycol) > WHERE ... > The keywords are separated :-( > > SELECT foo > FROM bar b > LEFT JOIN chair c USING (thekeycol) > WHERE ... > No more lineup :-( > > > > Admittedly, when you type it yourself, it's a bit annoying, because you > can't use just tabs. But if it's generated, it won't do any harm. > Why not giving PostgreSQL this extra portion of elegance... > > Regards, > Andreas > > -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_get_triggerdef in pg_dump
Rod Taylor wrote: Oh, one more thing --- right justify isn't as accepted as left-justify But it looks so much better... Ye! Consider this: SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... :-) versus SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... The keywords are separated :-( SELECT foo FROM bar b LEFT JOIN chair c USING (thekeycol) WHERE ... No more lineup :-( Admittedly, when you type it yourself, it's a bit annoying, because you can't use just tabs. But if it's generated, it won't do any harm. Why not giving PostgreSQL this extra portion of elegance... Regards, Andreas ---(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: [HACKERS] interval's and printing...
TODO updated: * Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle --- Larry Rosenman wrote: > > > --On Tuesday, June 24, 2003 10:44:25 -0400 Bruce Momjian > <[EMAIL PROTECTED]> wrote: > > > Larry Rosenman wrote: > >> >> > * Have SELECT '13 minutes'::interval display zero seconds > >> >> you might want to clarify the TODO to include in ISO DateStyle. > >> >> > >> >> (Per tom's comments). > >> > > >> > Can you supply an example/text? > >> * Have SELECT '13 minutes'::interval display zero seconds when using > >> DateStyle ISO > > > > I am still confused. What does such output look like. Right now I > > get: > > > > test=> SELECT '13 minutes'::interval; > > interval > > -- > > 00:13 > > (1 row) > > > > I assume the idea is to display it as 00:13:00, right? > Correct, but with Postgres DateStyle or SQL, it does other stuff: > > $ psql > Welcome to psql 7.3.3, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms >\h for help with SQL commands >\? for help on internal slash commands >\g or terminate with semicolon to execute query >\q to quit > > ler=# set datestyle='postgres' > ler-# ; > SET > ler=# select '13 minutes'::interval > ler-# ; > interval > --- > @ 13 mins > (1 row) > > ler=# set datestyle='sql'; > SET > ler=# select '13 minutes'::interval; > interval > --- > @ 13 mins > (1 row) > > ler=# set datestyle='iso,us'; > SET > ler=# select '13 minutes'::interval; > interval > -- > 00:13 > (1 row) > > ler=# > > > > -- > > 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 > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > > > -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TO_CHAR SO SLOW???
Yes it is TO_CHAR, look like that OS ( SUN ) related issue, I assume PG uses some of the lib functions. Looks like nonsense for me, what is damn difficult in that ( formating dates ). going to try date_part, might help me. Too bad EXPLAIN does not provide statistic of time that spent inside a function call, would be much helpful in such case. In comparison with Microsoft SQL, productivity of using profiling/debugging tools sorry to say that, far behind. -Original Message- From: Karel Zak [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 1:04 AM To: Maksim Likharev Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] TO_CHAR SO SLOW??? On Mon, Jun 23, 2003 at 06:08:19PM -0700, Maksim Likharev wrote: > Hi, > I have some SQL function, just regular function selects data by using 4 > joins nothing fancy, > but one thing pretty noticeable, > I have to display 3 different columns with same date formatted > differently, > here are 3 different snippets: > > 1. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/') > FROM ( SELECT x, y, dt FROM ) AS t > ... > 2. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-') > FROM ( SELECT x, y, dt FROM ) AS t > .. > 3. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, > 'Mon-'), TO_CHAR(t.dt, '') > FROM ( SELECT x, y, dt FROM ) AS t > ... > > # 1: 15000 rows, I getting data for 130 sec > # 2: 15000 rows, I getting data for 160 sec > # 3: 15000 rows, I getting data for 220 sec > > adding different fields into output change query time only marginally > but adding or removing to_char, > just heavily knocks performance. > > is it TO_CHAR so slow?? I don't think to_char() is so slow. What happen with performance if you use t.dt without formatting or if try some other function an example extract()? SELECT t.x, t.y, t.dt FROM ( SELECT x, y, dt FROM ) AS t; SELECT t.x, t.y, EXTRACT(year from t.dt) FROM ( SELECT x, y, dt FROM ) AS t; Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ss_family in hba.c
On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote: > > I have applied a patch to CVS to fix the problem. It is all your patch, > except for the part you got from me, which was wrong. :-( > > It took me a while to realize the subtlety of your patch. First, it > removes the use of sa_family_t _except_ for cases that don't have > SOCKADDR_STORAGE, where it is required. Second, it allows for a > structure member named ss_family or __ss_family, tested via configure. > > This should fix most platforms. I am not sure how cygwin is going to > handle this --- we might have to add a specific sa_family_t typedef for > that platform --- MinGW does have sa_family_t, but probably doesn't need > it anyway. Testing for the size of sa_family_t is possible via > configure, but if only cygwin needs it, we can just hard-code that > platform in the template files. Cygwin folks, would you test CVS and > let me know. There are probably other systems that don't have sa_family_t yet, but they should be rather old. Even my Solaris 2.6 already seems to have it. What I was confused about is, is that cygwin seems to have a struct sockaddr_storage in the first place (in winsock2.h). I'm not sure what problem he really had since he only told it how he solved it. All that probably needed to change for cygwin was to no longer use sa_family_t in the getaddrinfo.c. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] lru cache replacement
On Wed, 25 Jun 2003 00:43:56 +0900 Yutaka tanida <[EMAIL PROTECTED]> wrote: > > BTW, when you were running your test case, what shared_buffers did you > > use? > > I use 16,64,256 and 4096. I missed. My shown result(+4% cache hit rate) is shared_buffers=64. --- Yutaka tanida<[EMAIL PROTECTED]> 謎のWebsite http://www.nonsensecorner.com/ ---(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: [HACKERS] lru cache replacement
On Tue, 24 Jun 2003 10:27:09 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > I tried to implement LRU-2 awhile ago, and got discouraged when I > couldn't see any performance improvement. But I was using pgbench as > the test case, and failed to think about its lack of seqscans. How about cache hit rate? > BTW, when you were running your test case, what shared_buffers did you > use? I use 16,64,256 and 4096. --- Yutaka tanida<[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] a problem with index and user define type
Tom Lane wrote:
Weiping He <[EMAIL PROTECTED]> writes:
we found the problem:
We used IMMUTABLE modifier in our CREATE FUNCTION definition,
though it's correct for our function to return same value if input the
same *data*,
but our data are passed by reference, not by value, so, some times we can't
retrive out data. Remove IMMUTABLE fixed the problem.
So, it seems to make it clear in docs would be a good help to function
writers, would commit a documentation patch later if necessary.
I'm not sure what problem you're really describing, but it would be
entirely wrong for the docs to claim that pass-by-reference datatypes
shouldn't have immutable functions. float8 is pass-by-ref, for
instance, but they don't come any more immutable than sqrt(x) ...
I'd suggest taking a closer look to understand what the problem really
is. Trying to index on a non-immutable function makes no sense, which
is why the system forbids it.
regards, tom lane
Sorry for didn't describe my problem clearly. I mean the function implement
the operator, like compare function for equal ('=') etc, not to build an
index
on an function.
Here is full version:
First we build a user type using CREATE FUNCTION, CREATE TYPE, CREATE
OPERATOR
and CREATE OPERATOR CLASS command, of course we wrote those C functions
needed for operator, type etc.
Then we try to test if our type (which is named UUID) could be
indexable, and found
it didn't use the index, but, we don't know why.
Later, we ask the question here why the index didn't get used, and you
point out that we
should assign the selective restriction function for our operators,
espically for '=' operator,
we use 'eqsel' per your suggestion. But found out that though the idnex
got used, but sometimes
not data row return (and sometimes we could get the data row)!
Then we re-check our definition, and found out may be we shouldn't use
IMMUTABLE
key word in the function definition used by the '=' operator to
implement the equation compare,
the wrong definition is:
Datum uuid_eq(PG_FUNCTION_ARGS)
{
struct uuid *uptr1 = (struct uuid *) PG_GETARG_POINTER(0);
struct uuid *uptr2 = (struct uuid *) PG_GETARG_POINTER(1);
PG_RETURN_BOOL(uuidcmp(uptr1, uptr2) == 0);
}
CREATE OR REPLACE FUNCTION uuid_eq(uuid, uuid)
RETURNS boolean
IMMUTABLE
STRICT
AS '$libdir/uuid'
LANGUAGE 'C';
CREATE OPERATOR = (
LEFTARG = uuid,
RIGHTARG = uuid,
COMMUTATOR = =,
NEGATOR = <>,
PROCEDURE = uuid_eq,
RESTRICT = eqsel,
JOIN = eqjoinsel
);
because the data type (UUID) is a struct,
and the uuid_eq() function accept two pointer to the value of struct uuid,
if make it IMMUTABLE, postgresql would think it should not try to run
the function, but return the cached value instead when it get two same
pointers input,
but, the pointers may be unchanged, the data pointers point to may have
changed.
So it will cause the weird symptom we found. And removed IMMUTABLE fix the
problem. So we think may be the doc for CREATE FUNCTION should point out
the difference of passed by ref and passed by value. Thus may avoid this
kind of
error.
Thanks and Regards
Laser
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_get_triggerdef in pg_dump
> Oh, one more thing --- right justify isn't as accepted as left-justify But it looks so much better... -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] lru cache replacement
> Yutaka tanida <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >> does pgbench test with relatively large sequential scans? > > > Probably no. > > pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be > very useful for testing a method that's mainly intended to prevent > seqscans from blowing out the cache. > > I tried to implement LRU-2 awhile ago, and got discouraged when I > couldn't see any performance improvement. But I was using pgbench as > the test case, and failed to think about its lack of seqscans. > > We could probably resurrect that code for comparison to 2Q, if anyone > can devise more interesting benchmark cases to test. > > BTW, when you were running your test case, what shared_buffers did you > use? It's very easy to test sequencial scans using pgbench: just drop the index from account table. I am using this technique to generate heavy loads. -- Tatsuo Ishii ---(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: [HACKERS] [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?
Joe Conway <[EMAIL PROTECTED]> writes: > Actually, adding a "pfree(oneres);" to the end of that for loop plugs > the memory leak and allows me to see the error message: On second look, you can't pfree oneres at the bottom of gen_cross_product() because it's part of the returned data structure --- note the assignment *iter++ = oneres; I think the bug here is that gen_cross_product should be ignoring argument positions that have nsupers == 0; those should always be assigned the same type as the input, since the regular type resolution algorithm is responsible for dealing with 'em. It might work to get rid of the "wild card" case (line 1115), which'd reduce the number of outputs to product(nsupers+1). I doubt we really want any wild cards in there anymore. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 10:44:25 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote: >> > * Have SELECT '13 minutes'::interval display zero seconds >> you might want to clarify the TODO to include in ISO DateStyle. >> >> (Per tom's comments). > > Can you supply an example/text? * Have SELECT '13 minutes'::interval display zero seconds when using DateStyle ISO I am still confused. What does such output look like. Right now I get: test=> SELECT '13 minutes'::interval; interval -- 00:13 (1 row) I assume the idea is to display it as 00:13:00, right? Correct, but with Postgres DateStyle or SQL, it does other stuff: $ psql Welcome to psql 7.3.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit ler=# set datestyle='postgres' ler-# ; SET ler=# select '13 minutes'::interval ler-# ; interval --- @ 13 mins (1 row) ler=# set datestyle='sql'; SET ler=# select '13 minutes'::interval; interval --- @ 13 mins (1 row) ler=# set datestyle='iso,us'; SET ler=# select '13 minutes'::interval; interval -- 00:13 (1 row) ler=# -- 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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: [HACKERS] interval's and printing...
Larry Rosenman wrote: > >> > * Have SELECT '13 minutes'::interval display zero seconds > >> you might want to clarify the TODO to include in ISO DateStyle. > >> > >> (Per tom's comments). > > > > Can you supply an example/text? > * Have SELECT '13 minutes'::interval display zero seconds when using > DateStyle ISO I am still confused. What does such output look like. Right now I get: test=> SELECT '13 minutes'::interval; interval -- 00:13 (1 row) I assume the idea is to display it as 00:13:00, right? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] lru cache replacement
Yutaka tanida <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> does pgbench test with relatively large sequential scans? > Probably no. pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be very useful for testing a method that's mainly intended to prevent seqscans from blowing out the cache. I tried to implement LRU-2 awhile ago, and got discouraged when I couldn't see any performance improvement. But I was using pgbench as the test case, and failed to think about its lack of seqscans. We could probably resurrect that code for comparison to 2Q, if anyone can devise more interesting benchmark cases to test. BTW, when you were running your test case, what shared_buffers did you use? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] interval's and printing...
--On Tuesday, June 24, 2003 09:46:33 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote: > > Add to TODO: > >* Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). Can you supply an example/text? * Have SELECT '13 minutes'::interval display zero seconds when using DateStyle ISO -- 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?
Joe Conway <[EMAIL PROTECTED]> writes: > Actually, adding a "pfree(oneres);" to the end of that for loop plugs > the memory leak and allows me to see the error message: Good catch. > Takes a while to check all 16777216 possibilities though, so I'm still > not sure more isn't needed here. I wonder why it's doing anything at all --- the check for supertypes ought to trigger only for complex type (rowtype) arguments, and there are none here. regards, tom lane ---(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: [HACKERS] a problem with index and user define type
Weiping He <[EMAIL PROTECTED]> writes: > we found the problem: > We used IMMUTABLE modifier in our CREATE FUNCTION definition, > though it's correct for our function to return same value if input the > same *data*, > but our data are passed by reference, not by value, so, some times we can't > retrive out data. Remove IMMUTABLE fixed the problem. > So, it seems to make it clear in docs would be a good help to function > writers, would commit a documentation patch later if necessary. I'm not sure what problem you're really describing, but it would be entirely wrong for the docs to claim that pass-by-reference datatypes shouldn't have immutable functions. float8 is pass-by-ref, for instance, but they don't come any more immutable than sqrt(x) ... I'd suggest taking a closer look to understand what the problem really is. Trying to index on a non-immutable function makes no sense, which is why the system forbids it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
Joe Conway <[EMAIL PROTECTED]> writes: > Yeah. But we'd need to detect whether or not the Oracle client libs are > available. I'm not sure how to do that with the contrib build system. > And we'd need a fair amount of integration/reorganizing the existing > code. Also, I've got the same issues with integrating jdbclink. > I don't think I'll be able to get that done between now and July 1st. Seems reasonable to put integrating both of 'em as a TODO for 7.5. I think you're clearly the guy who has to review those patches, so if you don't have time right now, it's not gonna happen for 7.4. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
Patch removed at author's request. --- Yutaka tanida wrote: > Hi. > > I implement 2Q algorithm to PostgreSQL for buffer management , instead > of LRU. > It's known as low overhead and high performance than LRU. If you have > some interests , see following URL. > > http://www.vldb.org/conf/1994/P439.PDF > > In my test (pgbench -S) , it improves 4% cache hit rate and 2% up > performance comparing from LRU. > > Do you have any interest about this patch? > > -- > Yutaka tanida <[EMAIL PROTECTED]> > http://www.nonsensecorner.com/ [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
OK, thanks. I will remove it from the queue, and someone suggested a different algorithm today: > I was researching on cache replacement strategy as well. 2Q has one > disadvantage see this exellent paper: > http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper > "ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One > Up on LRU" for implementation details. ARC requires no tuning and can > switch fast between chaging patterns. Best of all is it is resistant to a > "sequential scan" pattern. and i think it's even easier to implement then > 2q :) --- Yutaka tanida wrote: > > On Mon, 23 Jun 2003 23:49:17 -0400 (EDT) > Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > > Looks good to me --- we will include it in 7.4. > > Thanks.But please note it is not completed yet. I must implement more , > and move configurable parameter to postgresql.conf file. > > -- > Yutaka tanida <[EMAIL PROTECTED]> > http://www.nonsensecorner.com/ > > > ---(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 > -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] interval's and printing...
Larry Rosenman wrote: > > > > Add to TODO: > > > > * Have SELECT '13 minutes'::interval display zero seconds > you might want to clarify the TODO to include in ISO DateStyle. > > (Per tom's comments). Can you supply an example/text? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL Core Welcomes New Member
It's rumoured that Vince Vielhaber once said: > Whut? Please drop www.us as a postgresql mirror. Just stop rsyncing and your mirror will be dropped automatically. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_triggerdef in pg_dump
Andreas Pflug wrote: > I also could implement line break and indentation formatting. I > implemented a keyword-based algorithm in pgAdmin3, and having the > original tree the job is obviously easier. Do we need any flexibility > about indent char (tab or space) and indentation size (2 chars)? The > pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they > line up nicely, and I'd prefer doing it this way again. > > SELECT foo >FROM bar b >JOIN chair c USING (thekeycol) > WHERE ... Oh, one more thing --- right justify isn't as accepted as left-justify --- sorry. > SELECT foo > FROM bar b > JOIN chair c USING (thekeycol) > WHERE ... -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_get_triggerdef in pg_dump
Great. I recommend using spaces rather than tabs for indenting in psql
and pg_dump.
---
Andreas Pflug wrote:
>
>
> Bruce Momjian wrote:
>
> >OK, added to TODO:
> >
> > Modify pg_get_triggerdef() to take a boolean to pretty-print,
> > and use that as part of pg_dump along with psql
> >
> >Andreas, can you work on this? I like the idea of removing extra
> >parens, and merging it into the existing code rather than into contrib
> >makes sense.
> >
>
> Yes, I can. At the moment, I have a runnable contrib module, which
> replaces all pg_get_xxxdef by pg_get_xxxdef2 functions. It's no problem
> to apply that code back to the original ruleutils.c when the
> isSimpleNode algorithm is reviewed independently and proved being correct.
>
> For safety reasons, I can make this dependent on a bool pretty-print
> parameter.
>
> I also could implement line break and indentation formatting. I
> implemented a keyword-based algorithm in pgAdmin3, and having the
> original tree the job is obviously easier. Do we need any flexibility
> about indent char (tab or space) and indentation size (2 chars)? The
> pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they
> line up nicely, and I'd prefer doing it this way again.
>
> SELECT foo
>FROM bar b
>JOIN chair c USING (thekeycol)
> WHERE ...
>
>
>
> Regards,
>
> Andreas
>
> /***
> * check if given node is simple.
> * false : not simple
> * true : simple in the context of parent node's type
> ***/
>
> static bool isSimpleNode(Node *node, NodeTag parentNodeType)
> {
> if (!node)
> return true;
>
> switch (nodeTag(node))
> {
> // single words: always simple
> case T_Var:
> case T_Const:
> case T_Param:
>
> // function-like: name(..) or name[..]
> case T_ArrayRef:
> case T_FuncExpr:
> case T_ArrayExpr:
> case T_CoalesceExpr:
> case T_NullIfExpr:
> case T_Aggref:
>
> // CASE keywords act as parentheses
> case T_CaseExpr:
> return true;
>
> // appears simple since . has top precedence, unless parent is T_FieldSelect
> itself!
> case T_FieldSelect:
> return (parentNodeType == T_FieldSelect ? false : true);
>
>
> // maybe simple, check args
> case T_CoerceToDomain:
> return isSimpleNode((Node*) ((CoerceToDomain*)node)->arg,
> T_CoerceToDomain);
> case T_RelabelType:
> return isSimpleNode((Node*) ((RelabelType*)node)->arg, T_RelabelType);
>
>
> // depends on parent node type; needs further checking
> case T_SubLink:
> case T_NullTest:
> case T_BooleanTest:
> case T_OpExpr:
> case T_DistinctExpr:
> if (parentNodeType == T_BoolExpr)
> return true;
> // else check the same as for T_BoolExpr; no break here!
> case T_BoolExpr:
> switch (parentNodeType)
> {
> case T_ArrayRef:
> case T_FuncExpr:
> case T_ArrayExpr:
> case T_CoalesceExpr:
> case T_NullIfExpr:
> case T_Aggref:
> case T_CaseExpr:
> return true;
> default:
> break;
> }
> return false;
>
> // these are not completely implemented; so far, they're simple
> case T_SubPlan:
> case T_CoerceToDomainValue:
> return true;
>
> default:
> break;
> }
> // those we don't know: in dubio complexo
> return false;
> }
>
>
>
>
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
>
--
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 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
[HACKERS] How to use pset command in my program!!
Hi! I want to use 'pset'command in my program it's like this. I want to do the execute the following in my program. \pset null 'ALL' how can this be done bye srikanth ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] lru cache replacement
xoror, On Tue, 24 Jun 2003 12:13:51 +0200 (MEST) [EMAIL PROTECTED] wrote: > I was researching on cache replacement strategy as well. 2Q has one > disadvantage see this exellent paper: > http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper > "ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One > Up on LRU" for implementation details. ARC requires no tuning and can > switch fast between chaging patterns. Best of all is it is resistant to a > "sequential scan" pattern. and i think it's even easier to implement then > 2q :) Thanks for your information. I check the paper and implement it by Java for testing. > does pgbench test with relatively large sequential scans? Probably no. -- Yutaka tanida <[EMAIL PROTECTED]> http://www.nonsensecorner.com/ ---(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: [CYGWIN] [HACKERS] ss_family in hba.c
Bruce, On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote: > This should fix most platforms. I am not sure how cygwin is going to > handle this --- we might have to add a specific sa_family_t typedef > for that platform --- MinGW does have sa_family_t, but probably > doesn't need it anyway. Testing for the size of sa_family_t is > possible via configure, but if only cygwin needs it, we can just > hard-code that platform in the template files. Cygwin folks, would > you test CVS and let me know. The above seems to be OK for Cygwin too. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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: [HACKERS] 2Q implementaion for PostgreSQL buffer replacement.
On Mon, 23 Jun 2003 23:49:17 -0400 (EDT) Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Looks good to me --- we will include it in 7.4. Thanks.But please note it is not completed yet. I must implement more , and move configurable parameter to postgresql.conf file. -- Yutaka tanida <[EMAIL PROTECTED]> http://www.nonsensecorner.com/ ---(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: [HACKERS] sa_family_t in cygwin compile of cvs + regression failure
Bruce, On Mon, Jun 23, 2003 at 09:50:49PM -0400, Bruce Momjian wrote: > OK, patch applied to typedef sa_family_t for cygwin. If other > platforms need it, I will have to do something more generic. I'm happy to report that the above patch solves one of Cygwin's current build problems. However, Cygwin still needs the following patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00186.php Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_get_triggerdef in pg_dump
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into contrib
makes sense.
Yes, I can. At the moment, I have a runnable contrib module, which
replaces all pg_get_xxxdef by pg_get_xxxdef2 functions. It's no problem
to apply that code back to the original ruleutils.c when the
isSimpleNode algorithm is reviewed independently and proved being correct.
For safety reasons, I can make this dependent on a bool pretty-print
parameter.
I also could implement line break and indentation formatting. I
implemented a keyword-based algorithm in pgAdmin3, and having the
original tree the job is obviously easier. Do we need any flexibility
about indent char (tab or space) and indentation size (2 chars)? The
pgAdmin3 algorithm uses 4 spaces, and tries to align keywords so they
line up nicely, and I'd prefer doing it this way again.
SELECT foo
FROM bar b
JOIN chair c USING (thekeycol)
WHERE ...
Regards,
Andreas
/***
* check if given node is simple.
* false : not simple
* true : simple in the context of parent node's type
***/
static bool isSimpleNode(Node *node, NodeTag parentNodeType)
{
if (!node)
return true;
switch (nodeTag(node))
{
// single words: always simple
case T_Var:
case T_Const:
case T_Param:
// function-like: name(..) or name[..]
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
// CASE keywords act as parentheses
case T_CaseExpr:
return true;
// appears simple since . has top precedence, unless parent is T_FieldSelect
itself!
case T_FieldSelect:
return (parentNodeType == T_FieldSelect ? false : true);
// maybe simple, check args
case T_CoerceToDomain:
return isSimpleNode((Node*) ((CoerceToDomain*)node)->arg,
T_CoerceToDomain);
case T_RelabelType:
return isSimpleNode((Node*) ((RelabelType*)node)->arg, T_RelabelType);
// depends on parent node type; needs further checking
case T_SubLink:
case T_NullTest:
case T_BooleanTest:
case T_OpExpr:
case T_DistinctExpr:
if (parentNodeType == T_BoolExpr)
return true;
// else check the same as for T_BoolExpr; no break here!
case T_BoolExpr:
switch (parentNodeType)
{
case T_ArrayRef:
case T_FuncExpr:
case T_ArrayExpr:
case T_CoalesceExpr:
case T_NullIfExpr:
case T_Aggref:
case T_CaseExpr:
return true;
default:
break;
}
return false;
// these are not completely implemented; so far, they're simple
case T_SubPlan:
case T_CoerceToDomainValue:
return true;
default:
break;
}
// those we don't know: in dubio complexo
return false;
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ftp mirror
> -Original Message- > From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED] > Sent: 24 June 2003 02:55 > To: [EMAIL PROTECTED]; pgsql-hackers list > Subject: Re: [HACKERS] ftp mirror > > > > Is it me or is there a problem with ftp mirrors? > > The latest shapshots I have here are from June 2; seems rather old.. > > Also, what happened to www.au.postgresql.org??? My fault, sorry. I've asked Marc to fix the DNS. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TO_CHAR SO SLOW???
On Mon, Jun 23, 2003 at 06:08:19PM -0700, Maksim Likharev wrote: > Hi, > I have some SQL function, just regular function selects data by using 4 > joins nothing fancy, > but one thing pretty noticeable, > I have to display 3 different columns with same date formatted > differently, > here are 3 different snippets: > > 1. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/') > FROM ( SELECT x, y, dt FROM ) AS t > ... > 2. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, 'Mon-') > FROM ( SELECT x, y, dt FROM ) AS t > .. > 3. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/'), TO_CHAR(t.dt, > 'Mon-'), TO_CHAR(t.dt, '') > FROM ( SELECT x, y, dt FROM ) AS t > ... > > # 1: 15000 rows, I getting data for 130 sec > # 2: 15000 rows, I getting data for 160 sec > # 3: 15000 rows, I getting data for 220 sec > > adding different fields into output change query time only marginally > but adding or removing to_char, > just heavily knocks performance. > > is it TO_CHAR so slow?? I don't think to_char() is so slow. What happen with performance if you use t.dt without formatting or if try some other function an example extract()? SELECT t.x, t.y, t.dt FROM ( SELECT x, y, dt FROM ) AS t; SELECT t.x, t.y, EXTRACT(year from t.dt) FROM ( SELECT x, y, dt FROM ) AS t; Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] again: Bug #943: Server-Encoding from EUC_TW toUTF-8
> > > I reported bug #943 (I found in 7.3.2) and you checked in some change against > > > integer overflow. > > > Now I upgraded to 7.3.3 and I'm not happy with this. > > > The exact error as I described is fixed, but I found new errors in conversion > > > UTF-8 <-> EUC_TW and BIG5: > > > > > > Copy to table (DB has UTF-8 encoding) from file: > > > for PGCLIENTENCODING=BIG5: > > > WARNING: copy: line 1, LocalToUtf: could not convert (0xf9d6) BIG5 to UTF-8. > > > Ignored > > > WARNING: copy: line 2, LocalToUtf: could not convert (0xf9d7) BIG5 to UTF-8. > > > Ignored > > > WARNING: copy: line 3, LocalToUtf: could not convert (0xf9d8) BIG5 to UTF-8. > > > Ignored > > > WARNING: copy: line 4, LocalToUtf: could not convert (0xf9db) BIG5 to UTF-8. > > > Ignored > > > > I see no problem here. The only standard conversion map I could found > > on-line form so far (see below URL) does not include entries 0xf9d6 or > > above. > > > > http://www.unicode.org/Public/UNIDATA/Unihan.txt > > > I found in this file: > U+F9D7 in line 604519 > U+F9D8 in line 219540 > U+F9D6...U+F9DB in lines 730707...730766. No. U+F9D6 means *Unicode* code point, not BIG5 code point. > > > > for EUC_TW > > > WARNING: copy: line 1, LocalToUtf: could not convert (0x8ea3c3b7) EUC_TW to > > > UTF-8. Ignored > > > WARNING: copy: line 2, LocalToUtf: could not convert (0x8ea3cfd0) EUC_TW to > > > UTF-8. Ignored > > > WARNING: copy: line 3, LocalToUtf: could not convert (0x8ea3c4ce) EUC_TW to > > > UTF-8. Ignored > > > WARNING: copy: line 4, LocalToUtf: could not convert (0x8ea3bdfe) EUC_TW to > > > UTF-8. Ignored > > > > Hum. These seem to be CNS 11643-1993, plane 3. Currently PostgreSQL > > supports only: > > > > CNS 11643-1993, plane 0 > > CNS 11643-1993, plane 1 > > CNS 11643-1993, plane 2 > > CNS 11643-1993, plane 15 > > > > Would you like to have support for rest of CNS 11643-1993 planes: > > > > CNS 11643-1993, plane 3 > > CNS 11643-1993, plane 4 > > CNS 11643-1993, plane 5 > > CNS 11643-1993, plane 6 > > CNS 11643-1993, plane 7 > > > > support for upcoming 7.4? > > > > > Copy out to file from table (UTF-8 data): > > > to BIG5 > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe7a281). Ignored > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe98ab9). Ignored > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe8a38f). Ignored > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe7b2a7). Ignored > > > > > > to EUC_TW is ok! > > > > BIG5 and EUC_TW have different code points. So this is not very strange. > > > But it is very strange that I can (for EUC_TW) copy to file without error but I can > not copy from file without error. > > Michael > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] interval's and printing...
--On Monday, June 23, 2003 23:41:29 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Add to TODO: * Have SELECT '13 minutes'::interval display zero seconds you might want to clarify the TODO to include in ISO DateStyle. (Per tom's comments). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?
Joe Conway wrote:
I get nanswers = 16777216, so right off the bat 67MB or so is allocated.
Then there's this:
/* compute the cross product from right to left */
for (;;)
{
oneres = (Oid *) palloc0(FUNC_MAX_ARGS * sizeof(Oid));
I'm guessing this gets executed nanswers times. I saw memory usage grow
to 880 MB and then killed the process.
I'm not sure of the best way to fix this yet, but I found that when
calling the function with argument types matching the prototype
perfectly, this code never gets executed.
Actually, adding a "pfree(oneres);" to the end of that for loop plugs
the memory leak and allows me to see the error message:
ERROR: Function add_news__test(integer, character varying, timestamp
with time zone, character varying, character varying, character varying,
character varying, integer, timestamp with time zone, integer, timestamp
with time zone, character varying, character varying, character varying,
integer, boolean, character varying, character varying, character
varying, timestamp with time zone, integer, character varying, character
varying, integer) does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
Takes a while to check all 16777216 possibilities though, so I'm still
not sure more isn't needed here.
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
