Re: [HACKERS] PREPARE and transactions
I would be fine with changing the lifetime if an EXECUTE failure did not abort the current transaction. Then I could simply watch the return code of the statement execution and prepare the statement on demand...from my point of view, this would actually be the most elegant scenario. BEGIN; ... do something ... ; SUBBEGIN; EXECUTE ...; -- if it fails: -- SUBABORT; -- PREPARE ...; -- SUBBEGIN; -- EXECUTE ...; -- can continue as if nothing happened SUBCOMMIT; COMMIT; This is not an option: this requires that every EXECUTE be wrapped with a subtransaction. This is a performance killer because it (at minimum) triples my statement turnaround latency. With the current behavior, you can guarantee certain behaviors by wrapping PREPARE/DEALLOCATE... and I was eagerly anticipating your work to do this. I would much rather do that than be required to wrap every single EXECUTE (recall that most of my I/O goes through prepared statements). Merlin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] warning missing
Gaetano, I've been using C++ for 15 years and Java for 7. I like them both. Every language has its pros and cons. C++ can be extremely powerful in the hands of someone who knows how to use it. I actually wrote the first version of Pl/Java in C++. However, I got strong advice to rewrite it using plain C (which I did) to get maximum acceptance. Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PREPARE and transactions
On Sat, Jun 26, 2004 at 09:12:33AM -0400, Merlin Moncure wrote: BEGIN; ... do something ... ; SUBBEGIN; EXECUTE ...; -- if it fails: -- SUBABORT; -- PREPARE ...; -- SUBBEGIN; -- EXECUTE ...; -- can continue as if nothing happened SUBCOMMIT; COMMIT; This is not an option: this requires that every EXECUTE be wrapped with a subtransaction. This is a performance killer because it (at minimum) triples my statement turnaround latency. Ah, good point. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo (Jaime Salinas) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] nested xacts and phantom Xids
Alvaro Herrera [EMAIL PROTECTED] writes: It has been suggested a couple of times that we should use a different syntax for subtransactions than for main transactions. This would for example allow things like BEGIN; do something; SUBBEGIN; It might be awkward for clients like psql that will want to execute every command in a nested transaction. It would mean they would have to know whether the user has started a transaction or not in order to know whether to use BEGIN or SUBBEGIN. But I guess they would have to do that anyways unless there's some protocol level way to indicate a query should be executed in a nested transaction. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] recursive SQL
jacob koehler (RRes-Roth) wrote: hi, i am wondering what you think about including evgen potemkin's patch for recursive SQL in the next postgres version: http://gppl.terminal.ru/ [snip] - Evgen DID publish this patch under GPL, see: http://gppl.terminal.ru/README.html It would first have to be relicensed ... cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] recursive SQL
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 26 June 2004 20:42 To: [EMAIL PROTECTED] Subject: Re: [HACKERS] recursive SQL jacob koehler (RRes-Roth) wrote: hi, i am wondering what you think about including evgen potemkin's patch for recursive SQL in the next postgres version: http://gppl.terminal.ru/ [snip] - Evgen DID publish this patch under GPL, see: http://gppl.terminal.ru/README.html It would first have to be relicensed ... it would be interesting to know if it would be included, IFF the author publishes it under BSD. (the authors webpage gives the impression that he is happy to share it. the fact that the reference to GPL is well hidden in the authors webpage, indicates that the author did not really think much about which license he chooses, i.e. he might be happy to change to BSD.) as i said, i think the lack of recursive queries (whatever syntax they are in) are one of the major drawbacks of postgres when compared to other databases. cheers, jacob ---(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] xeon processors
On Fri, 2004-06-25 at 14:13, Jaime Casanova wrote: Hi all, Can anyone tell me if postgresql has problems with xeon processors? If so, there is any fix or project of fix it? To PostgreSQL, there's no difference between a dual CPU machine with no hyperthreading, and a single CPU machine with hyperthreading. HOWEVER, there have been some issues with certain Operating Systems running slower with hyperthreading enabled than without it. Late model Linux kernels (2.6) seem to have gotten enough logic into the scheduler to get good performance on a hyperthreaded system. ---(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] [DEFAULT] Daily digest v1.4537 (18 messages)
Jacob, cons: - its not standard SQL (uses oracle style syntax) Which is, plain and simple, a deal-breaker. You can count on me to vote against inclusion of any patch which uses non-standard SQL when a standard syntax is available. Further, the IS_CONNECTED_BY() function is available in /contrib/tablefunc. I fail to see why the Evgen patch is even necessary. More Cons: -- The patch has shown some significant performance issues according to the reports of several people on the performance list who have used it.This is likely due to insufficient understanding of planner estimates. -- The patch has several serious bugs. One of them, apparently by report on pgsql-sql, is truncation of strings at the 8K page limit (in other words, a lack of integration with TOAST). - it would add a feature that many people miss already for ages. all existing workarounds are a pain in the ass, and are too slow for realistic applications. Huh. I've written 4-5 applications which required recursive queries in the last 3 years. All of them worked with PL/pgSQL or C recursive functions; performance was even pretty good. - full SQL99 compliant recursive queries are much more complex, i.e. i think it is even unlikely that they will find their way into 7.6. Currently, nobody is working on SQL99/2003 recursive queries. So, you are correct, there is no timeline for inclusion. You could fix this. Get hacking, or hire a hacker. - Evgen DID publish this patch under GPL, see: We are a BSD project. So we cannot include any GPL patches, even if we wanted to. - the code doesnt look too bad (although im not the right person to judge such things), and it seems the developer takes care of bugfixes (and possibly also feature requests like sql99 compliance?), i.e. this might be a realistic startingpoint for SQL99 compliant recursive queries. But it's not. Oracle's IS CONNECTED BY syntax is very different from the SQL99 syntax, and some of the math is different. If anything, implementing the Evgen patch would complicate implementation of the SQL99 syntax. i am aware of the fact that tom lane pointed to the fact that Andrew Overholt did work towards SQL99 compliant recursive queries. it would be interesting to know andrews opinion how much more work would be needed to get a SQL99 compliant version out based on the work he has done so far This is the line you should pursue, rather than trying to get people to accept Evgen's patch. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] recursive SQL
- Evgen DID publish this patch under GPL, see: http://gppl.terminal.ru/README.html We cannot use GPL code in PostgreSQL. PostgreSQL is BSD licensed. As to why on earth he GPL'd - I have no idea... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] recursive SQL
jacob koehler (RRes-Roth) [EMAIL PROTECTED] writes: It would first have to be relicensed ... it would be interesting to know if it would be included, IFF the author publishes it under BSD. This patch has been proposed and rejected before. It doesn't do the SQL-standard syntax for recursion, and I have little faith in the implementation even if it did the right syntax. There has been some work done towards implementing the spec-compatible syntax, but it's not likely to get finished in time for 7.5 :-( regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
