[HACKERS] Design Documentation Help !!
Hello , Can i get any design documentation apart from the readme files and the comments those are available with the source code . In particular any document explaining the data structures related to optimizer and executor parts of the system Thansk in adv, -regards Ramu _ Easiest Money Transfer to India. Send Money To 6000 Indian Towns. http://go.msnserver.com/IN/42198.asp Easiest Way To Send Money Home! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Summary of Changes since last release (7.4.1)
Simon, On Thu, 19 Feb 2004 00:05:15 -, Simon Riggs [EMAIL PROTECTED] wrote: POSTGRESQL: Summary of Changes since last release (7.4.1) -- 18 Feb 2004 this is getting long over time. If you plan to post it once a week, flagging items that are new or have changed might help keeping track of what's going on. - Index performance improved when scanning highly non-unique indices; ! Index performance improved when scanning highly non-unique indices; or - (updated) Index performance improved ... - ANALYZE will now collect statistics on expressional indexes, and make + ANALYZE will now collect statistics on expressional ... or - (new) ANALYZE will now collect statistics on expressional ... Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
I believe the ODBC driver uses CTID for this sort of problem. CTID is guaranteed to exist and to be fast to access (since it's a physical locator). Against this you have the problem that concurrent updates of the record will move it, leaving your CTID invalid. However, that IIRC the ctid access follows the chain up to the currently valid tuple ? I thought the only enemy of ctid access was vacuum ? 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] [PATCHES] NO WAIT ...
The question is whether we should have a GUC variable to control no waiting on locks or add NO WAIT to specific SQL commands. Does anyone want to vote _against_ the GUC idea for nowait locking. (We already have two voting for such a variable.) I vote against. We got bit by both the regex and the autocommit GUC vars and this is setting up to cause a similar headache with old code on new platforms. I vote for the GUC. Imho it is not comparable to the autocommit case, since it does not change the way your appl needs to react (appl needs to react to deadlock already). I personally think a wait period in seconds would be more useful. Milli second timeouts tend to be misused with way too low values in this case, imho. Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] NO WAIT ...
Zeugswetter Andreas SB SD wrote: The question is whether we should have a GUC variable to control no waiting on locks or add NO WAIT to specific SQL commands. Does anyone want to vote _against_ the GUC idea for nowait locking. (We already have two voting for such a variable.) I vote against. We got bit by both the regex and the autocommit GUC vars and this is setting up to cause a similar headache with old code on new platforms. I vote for the GUC. Imho it is not comparable to the autocommit case, since it does not change the way your appl needs to react (appl needs to react to deadlock already). I personally think a wait period in seconds would be more useful. Milli second timeouts tend to be misused with way too low values in this case, imho. I understand, but GUC lost the vote. I have updated the TODO list to indicate this. Tatsuo posted a patch to add NO WAIT to the LOCK command, so we will see if we can get that into CVS. -- 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] OIDs, CTIDs, updateable cursors and friends
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: IIRC the ctid access follows the chain up to the currently valid tuple ? No. I think Hiroshi or someone put in a function you can use to follow the chain, but a simple WHERE ctid = whatever won't do it. In any case, if you're not holding an open transaction then you have to be prepared to have the dead tuple vacuumed out from under you, in which case you'd not be able to follow the chain anyway. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] NO WAIT ...
I vote for the GUC. Imho it is not comparable to the autocommit case, since it does not change the way your appl needs to react (appl needs to react to deadlock already). Wrote one program a while ago that was very time sensitive. By the time deadlock detection had been kicked off, the data was already invalid and due to be replaced -- thus, it's impossible to have deadlocks with the chosen design for that application. The point is, PostgreSQL is fairly versatile and is a component of many different environments. Method X might be great for what you're doing, but it doesn't apply across the board. The regex GUC doesn't impact a majority of applications either, but it proved catastrophic to some. ---(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] [PATCHES] NO WAIT ...
I personally think a wait period in seconds would be more useful. Milli second timeouts tend to be misused with way too low values in this case, imho. I understand, but GUC lost the vote. I have updated the TODO list to indicate this. Tatsuo posted a patch to add NO WAIT to the LOCK command, so we will see if we can get that into CVS. Ok, I can see the advantages of that approach too. Too bad there is no standard for this. And it is probably really true that statement_timeout solves the problem of very long (indefinite :-) waits for locks. Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Replication eRServer problems
On Mon, Feb 16, 2004 at 10:16:39AM -0800, John Li wrote: I just implemented eRServer for one of my clients and found many problems with it. Yep. There's a list dedicated to it, by the way, available through the gborg site. 1.It crashes when using ?ers_addtable? to add big tables. The problem is that it used pg_dump ?d then tried to read the whole output in memory. I fixed it by reading one row at a time and inserting it to slave. The setup scripts are pretty buggy. 3.There was no index created on ?_ers_uniq? on slave side. It took minutes per transaction to delete on huge tables. After I found the problem and created index on the column, it only took about 5 milliseconds to delete. This is a new report. Thanks. Hope those will be fixed in the next version. I can also provide my fixes if needed. I'm interested in seeing patches, for sure. I'll be applying some things this weekend, so I'll test for the cases you mention and hit you up for patches once I'm done. A -- Andrew Sullivan | [EMAIL PROTECTED] This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Advice regarding configuration parameters
Thomas Hallgren wrote: Some very good suggestions where made here. What happens next? Will this end up in a TODO list where someone can claim the task (I'm trying to learn how the process works) ? If someone doesn't jump right on it and make a diff -c proposal, it probably belongs on the TODO list. If your need is sufficiently high, and you have the time to take it on, then go for it ;-). If not, I might someday, but no promises for 7.5. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Advice regarding configuration parameters
Joe Conway wrote: Thomas Hallgren wrote: Some very good suggestions where made here. What happens next? Will this end up in a TODO list where someone can claim the task (I'm trying to learn how the process works) ? If someone doesn't jump right on it and make a diff -c proposal, it probably belongs on the TODO list. If your need is sufficiently high, and you have the time to take it on, then go for it ;-). If not, I might someday, but no promises for 7.5. I assume this is regarding disabling of triggers. We already have that on the TODO list: * Allow triggers to be disabled [trigger] -- 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] Design Documentation Help !!
Ramanujam H S Iyengar [EMAIL PROTECTED] writes: Can i get any design documentation apart from the readme files and the comments those are available with the source code . Not really. There's some information in the Internals section of the main docs: http://www.postgresql.org/docs/7.4/static/internals.html But that could probably do with a lot of improvement. If you're new to DBMS internals, I'd also suggest picking up a textbook on the subject. I've personally used Database Management Systems by Ramakrishnan and Gehkre -- it's quite good. -Neil ---(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] casting zero-length strings
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Either way, we should make them a WARNING for 7.5, then error in 7.6. Ok, I'll make this change soon. If we end up marking more 7.5 changes using this mechanism (i.e. deprecate for 7.5, disallow for 7.6), we could use an #ifdef symbol to mark all the changes that need to be made permanent for 7.6: #ifdef 7_5_DEPRECATED_FUNCTIONALITY ... #endif Cheers, Neil ---(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] 7.4.1 release status - Turkish Locale
Sorry for rising up old issue again but the problem still persists. And database cluster is not being created with Turkish locale If you have any doubts about how Turkish users will react to the fact that both I and I WITH DOT will be treated as same character, rest assured that this behavior is de-facto standard when it comes to file names, identifiers and commands. Greg Stark and Devrim Gunduz will confirm that, no doubt. Please review and apply this patch I send you for the third time. You will not regret and many users will be grateful. Please note that to my knowledge it will not break any other locales. Best regards, Nicolai tr20040203.diff Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Advice regarding configuration parameters
No, this was not related to triggers at all. The original discussion concerned GUC functionality to handle configuration settings for pllang extensions. - thomas - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Joe Conway [EMAIL PROTECTED] Cc: Thomas Hallgren [EMAIL PROTECTED]; Tom Lane [EMAIL PROTECTED]; Peter Eisentraut [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 21:00 Subject: Re: [HACKERS] Advice regarding configuration parameters Joe Conway wrote: Thomas Hallgren wrote: Some very good suggestions where made here. What happens next? Will this end up in a TODO list where someone can claim the task (I'm trying to learn how the process works) ? If someone doesn't jump right on it and make a diff -c proposal, it probably belongs on the TODO list. If your need is sufficiently high, and you have the time to take it on, then go for it ;-). If not, I might someday, but no promises for 7.5. I assume this is regarding disabling of triggers. We already have that on the TODO list: * Allow triggers to be disabled [trigger] -- 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] Advice regarding configuration parameters
Thomas Hallgren wrote: No, this was not related to triggers at all. The original discussion concerned GUC functionality to handle configuration settings for pllang extensions. OK. If you guys agree on TODO wording, I will add it. -- 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
