Re: [HACKERS] python / 7.4 / FC5 / x86_64
Andrew Dunstan [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Ideally, we would get Python to tell us the right location, because use lib64 if it exists isn't the right solution. Is this fixed somewhere post 7.4? Yes, but it was never backported. See: http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4 My recollection is that there are a number of interrelated changes going on there, and that a backport would have to touch a lot more than just the python stuff. So I'd recommend that it's not worth the trouble/risk. But if you want to have a go at extracting a small patch from the CVS history, have at it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
On Sep 1, 2006, at 5:05 , Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Well, the patch only multiplies by 30, so the interval would have to span +5 million years to overflow. I don't see any reason to add rounding until we get an actual query that needs it Have you tried your patch against the various cases that have been discussed in the past? In particular there were several distinct examples of this behavior posted at the beginning of the thread, and I'd not assume that a fix for one handles them all. Yes, it fixes all posted examples, except one that displays 23:60. I cannot reproduce that failure from Powerpc so am waiting for Michael to test it. Here's your patch tested on my machine, both with and without -- enable-integer-datetimes. I've tweaked the ad hoc test suite to include a case where the days and time differ in sign and added a couple of queries to the ad hoc test suite to include the problems Tom referred to--not that this patch will fix them, but to keep the known problems together. I hope to add more to this to test more edge cases. Unfortunately the problem still occur (see product_d), and --enable- integer-datetimes is pretty broken with this patch. Michael Glaesemann grzm seespotcode net -- test queries select interval '41 mon 12 days 360:00' * 0.3 as product_a , interval '-41 mon -12 days +360:00' * 0.3 as product_b , interval '-41 mon 12 days 360:00' * 0.3 as product_c , interval '-41 mon -12 days -360:00' * 0.3 as product_d; select interval '41 mon 12 days 360:00' / 10 as quotient_a , interval '-41 mon -12 days +360:00' / 10 as quotient_b , interval '-41 mon 12 days 360:00' / 10 as quotient_c , interval '-41 mon -12 days -360:00' / 10 as quotient_d; select interval '-12 days' * 0.3; select 1 * '100 hours'::interval as ten billion; set time zone 'EST5EDT'; select '2005-10-29 13:22:00-04'::timestamptz + '1 day'::interval as 2005-01-30 13:22:00-05; select '2005-10-30 13:22:00-05'::timestamptz - '2005-10-29 13:22:00-04'::timestamptz as a day; set time zone local; -- end test queries -- without --enable-integer-datetimes select interval '41 mon 12 days 360:00' * 0.3 as product_a , interval '-41 mon -12 days +360:00' * 0.3 as product_b , interval '-41 mon 12 days 360:00' * 0.3 as product_c , interval '-41 mon -12 days -360:00' * 0.3 as product_d; product_a | product_b | product_c |product_d --+- ++- 1 year 11 days 146:24:00 | -1 years -11 days +69:36:00 | -1 years -5 days +98:24:00 | -1 years -11 days -146:23:60.00 (1 row) select interval '41 mon 12 days 360:00' / 10 as quotient_a , interval '-41 mon -12 days +360:00' / 10 as quotient_b , interval '-41 mon 12 days 360:00' / 10 as quotient_c , interval '-41 mon -12 days -360:00' / 10 as quotient_d; quotient_a |quotient_b | quotient_c |quotient_d +--- +---+--- 4 mons 4 days 40:48:00 | -4 mons -4 days +31:12:00 | -4 mons -2 days +40:48:00 | -4 mons -4 days -40:48:00 (1 row) select interval '-12 days' * 0.3; ?column? -- -3 days -14:23:60.00 (1 row) select 1 * '100 hours'::interval as ten billion; ten billion -- 2147483647:00:00 (1 row) set time zone 'EST5EDT'; SET select '2005-10-29 13:22:00-04'::timestamptz + '1 day'::interval as 2005-01-30 13:22:00-05; 2005-01-30 13:22:00-05 2005-10-30 13:22:00-05 (1 row) select '2005-10-30 13:22:00-05'::timestamptz - '2005-10-29 13:22:00-04'::timestamptz as a day; a day 1 day 01:00:00 (1 row) set time zone local; SET -- with --enable-integer-datetimes select interval '41 mon 12 days 360:00' * 0.3 as product_a , interval '-41 mon -12 days +360:00' * 0.3 as product_b , interval '-41 mon 12 days 360:00' * 0.3 as product_c , interval '-41 mon -12 days -360:00' * 0.3 as product_d; product_a | product_b | product_c | product_d --+- ++-- 1 year 11 days 146:24:00 | -1 years -11 days +69:36:00 | -1 years -5 days +98:24:00 | -1 years -11 days -146:24:00 (1 row) select interval '41 mon 12 days 360:00' / 10 as quotient_a , interval '-41 mon -12 days +360:00' / 10 as quotient_b , interval '-41 mon 12 days 360:00' / 10 as quotient_c , interval '-41 mon -12 days -360:00' / 10 as quotient_d; quotient_a |quotient_b | quotient_c |quotient_d +---
Re: [HACKERS] GRANT role docs inconsistency
Magnus Hagander [EMAIL PROTECTED] writes:
The manual says:
GRANT role [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH ADMIN
OPTION ]
It doesn't say that anymore:
http://archives.postgresql.org/pgsql-committers/2006-08/msg00034.php
Perhaps we ought to start thinking about an 8.1 update release ---
we haven't had any forcing functions like security issues for awhile,
but we've accumulated a fair number of plain ol' bug fixes.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Interval month, week - day
Michael Glaesemann [EMAIL PROTECTED] writes: I came across some behavior that seems counterintuitive to me: test=# select '1.5 mon'::interval; interval - 1 mon 360:00:00 (1 row) With the time/day/month interval struct introduced in 8.1, I'd expect this to return '1 mon 15 days'. The reason is that the DecodeInterval converts fractional months to time directly, rather than cascading first to days. I agree that this seems like an oversight in the original months/days/seconds patch, rather than behavior we want to keep. But is DecodeInterval the only place with the problem? My recollection is that there's a certain amount of redundancy in the datetime code ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Interval month, week - day
On Sep 1, 2006, at 9:12 , Tom Lane wrote: Michael Glaesemann [EMAIL PROTECTED] writes: I came across some behavior that seems counterintuitive to me: test=# select '1.5 mon'::interval; interval - 1 mon 360:00:00 (1 row) With the time/day/month interval struct introduced in 8.1, I'd expect this to return '1 mon 15 days'. The reason is that the DecodeInterval converts fractional months to time directly, rather than cascading first to days. I agree that this seems like an oversight in the original months/days/seconds patch, rather than behavior we want to keep. But is DecodeInterval the only place with the problem? My recollection is that there's a certain amount of redundancy in the datetime code ... I'll check on this tonight. Any idea where I might start to look? Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Interval month, week - day
Michael Glaesemann [EMAIL PROTECTED] writes: On Sep 1, 2006, at 9:12 , Tom Lane wrote: I agree that this seems like an oversight in the original months/days/seconds patch, rather than behavior we want to keep. But is DecodeInterval the only place with the problem? I'll check on this tonight. Any idea where I might start to look? I'd look at the input routines for all the datetime types and see where they go. It's entirely possible that DecodeInterval is the only place with the problem, but I'd not assume that without looking. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] massive speedup on temp table creation/destruction?
I was just trying (unsuccessfully so far) to replicate Csaba Nagy's report of a strange failure with temp table creation. I made use of pgbench's recent improvements to be able to push random scripts at a collection of backends: $ cat ttscript.sql create temp table foo (f1 int); drop table foo; $ pgbench -n -c 98 -t 1000 -f ttscript.sql bench This is just pushing a long string of create temp table/drop table commands at a whole lot of backends concurrently. What I found surprising is that I get numbers like 430 tps from HEAD and 220 tps from REL8_1_STABLE. This test case is of course not about performance, but I'm not quite sure what we changed that would produce a 2X speedup from 8.1. Can anyone else replicate this? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Bruce Momjian [EMAIL PROTECTED] writes: I am unclear about this report. The patch was not meant to fix every interval issue, but merely to improve multiplication and division computations. Does it do that? According to Michael's last report, your patch fails under --enable-integer-datetimes. This is an issue where you have to be as simple as possible, but no simpler. I think the approach you are proposing is too simple. Michael's last patch here: http://archives.postgresql.org/pgsql-patches/2006-08/msg00447.php looks considerably more likely to lead to a workable answer. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
I am unclear about this report. The patch was not meant to fix every interval issue, but merely to improve multiplication and division computations. Does it do that? I think the 23:60 is a time rounding issue that isn't covered in this patch. I am not against fixing it, but does the submitted patch improve things or not? Given we are post-feature freeze, we don't have time to fix all the interval issues. --- Michael Glaesemann wrote: On Sep 1, 2006, at 5:05 , Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Well, the patch only multiplies by 30, so the interval would have to span +5 million years to overflow. I don't see any reason to add rounding until we get an actual query that needs it Have you tried your patch against the various cases that have been discussed in the past? In particular there were several distinct examples of this behavior posted at the beginning of the thread, and I'd not assume that a fix for one handles them all. Yes, it fixes all posted examples, except one that displays 23:60. I cannot reproduce that failure from Powerpc so am waiting for Michael to test it. Here's your patch tested on my machine, both with and without -- enable-integer-datetimes. I've tweaked the ad hoc test suite to include a case where the days and time differ in sign and added a couple of queries to the ad hoc test suite to include the problems Tom referred to--not that this patch will fix them, but to keep the known problems together. I hope to add more to this to test more edge cases. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am unclear about this report. The patch was not meant to fix every interval issue, but merely to improve multiplication and division computations. Does it do that? According to Michael's last report, your patch fails under --enable-integer-datetimes. Where does it fail? Here? select interval '41 mon 12 days 360:00' * 0.3 as product_a , interval '-41 mon -12 days +360:00' * 0.3 as product_b , interval '-41 mon 12 days 360:00' * 0.3 as product_c , interval '-41 mon -12 days -360:00' * 0.3 as product_d; product_a | product_b | product_c |product_d --+- ++- 1 year 11 days 146:24:00 | -1 years -11 days +69:36:00 | -1 years -5 days +98:24:00 | -1 years -11 days -146:23:60.00 - That is wrong, but I think we need another fix for that. Notice the problem is in minutes/seconds, not hours. This is an issue where you have to be as simple as possible, but no simpler. I think the approach you are proposing is too simple. Michael's last patch here: http://archives.postgresql.org/pgsql-patches/2006-08/msg00447.php looks considerably more likely to lead to a workable answer. I see he is taking the fractional part of the result and finding if that should round. I am confused why that would help the -146:23:60.00 value above. Notice we only see it for negative values too. I do like that he is rounding the computation spillover, and not the total time value, which is what I started with. I believe my provides a more accurate computation, and doesn't have the problems of rounding. The only bug we can find is the powerpc one for -146:23:60 minutes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Roadmaps 'n all that
[ hijacking this thread over to where the developers hang out ] Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: It's pointless to suppose that individual developers would really be answerable to any project-wide management, since that's not who they're paid by. So I tend to think that a project roadmap would be more of an exercise in wishful thinking than a useful management tool. OTOH it *could* be useful, if there are any developers out there wondering what they should work on next. Are there any ... and would they listen to a roadmap if they had one, rather than scratching their own itches? I would certainly listen to a roadmap if it talked to me ... Well, this question keeps coming up, and we keep arguing about it, and we still have no data to say whether it would work well for *this* project. Maybe it's time to take the bull by the horns. I propose a modest experiment: for the 8.3 development cycle, let's try to agree (in the next month or so) on a roadmap of what major features should be in 8.3 and who will make each one happen. A year from now, we will know whether this is a great thing we should continue, or we should stick to our traditional laissez-faire style of project management. I figure that even if it really sucks, it wouldn't kill us to try it for one release cycle --- at the very worst, we'd make up lost time in future by no longer needing to waste bandwidth arguing about it. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] massive speedup on temp table creation/destruction?
On 8/31/06, Tom Lane [EMAIL PROTECTED] wrote: I was just trying (unsuccessfully so far) to replicate Csaba Nagy's report of a strange failure with temp table creation. I made use of pgbench's recent improvements to be able to push random scripts at a collection of backends: $ cat ttscript.sql create temp table foo (f1 int); drop table foo; $ pgbench -n -c 98 -t 1000 -f ttscript.sql bench This is just pushing a long string of create temp table/drop table commands at a whole lot of backends concurrently. What I found surprising is that I get numbers like 430 tps from HEAD and 220 tps from REL8_1_STABLE. This test case is of course not about performance, but I'm not quite sure what we changed that would produce a 2X speedup from 8.1. Can anyone else replicate this? humm, you had me curious, so i ran the test. postgresql. 8.2 ~ 2 weeks recent number of clients: 98 number of transactions per client: 100 number of transactions actually processed: 9800/9800 tps = 216.424848 (including connections establishing) tps = 217.558450 (excluding connections establishing) 8.1: number of clients: 98 number of transactions per client: 100 number of transactions actually processed: 9800/9800 tps = 262.430496 (including connections establishing) tps = 263.977714 (excluding connections establishing) I did not confirm your results unfortunately. this is on quad opteron, totally stock freshly minted database cluster :-) I then did a cvs update on 8.2 just in case, and got: number of clients: 98 number of transactions per client: 100 number of transactions actually processed: 9800/9800 tps = 223.026519 (including connections establishing) tps = 224.233746 (excluding connections establishing) note i only did a 100 transactions, so the results are expected to be a bit more wild. merlin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Roadmaps 'n all that
On Aug 31, 2006, at 8:47 PM, Tom Lane wrote: [ hijacking this thread over to where the developers hang out ] Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: It's pointless to suppose that individual developers would really be answerable to any project-wide management, since that's not who they're paid by. So I tend to think that a project roadmap would be more of an exercise in wishful thinking than a useful management tool. OTOH it *could* be useful, if there are any developers out there wondering what they should work on next. Are there any ... and would they listen to a roadmap if they had one, rather than scratching their own itches? I would certainly listen to a roadmap if it talked to me ... Well, this question keeps coming up, and we keep arguing about it, and we still have no data to say whether it would work well for *this* project. Maybe it's time to take the bull by the horns. I propose a modest experiment: for the 8.3 development cycle, let's try to agree (in the next month or so) on a roadmap of what major features should be in 8.3 and who will make each one happen. A year from now, we will know whether this is a great thing we should continue, or we should stick to our traditional laissez-faire style of project management. I figure that even if it really sucks, it wouldn't kill us to try it for one release cycle --- at the very worst, we'd make up lost time in future by no longer needing to waste bandwidth arguing about it. Would this be a core postgresql code roadmap or something a bit broader (contrib, custom types, GUI-ish stuff, utilities and what have you)? Cheers, Steve ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] massive speedup on temp table creation/destruction?
Merlin Moncure [EMAIL PROTECTED] writes: On 8/31/06, Tom Lane [EMAIL PROTECTED] wrote: What I found surprising is that I get numbers like 430 tps from HEAD and 220 tps from REL8_1_STABLE. This test case is of course not about performance, but I'm not quite sure what we changed that would produce a 2X speedup from 8.1. Can anyone else replicate this? I did not confirm your results unfortunately. this is on quad opteron, I was trying it on a dual Xeon EM64T with hyperthreading on ... I wonder if we've unintentionally done something that optimizes for that platform? I don't make any claim that this test case is interesting in itself, but it might be telling us something about more-mainstream cases. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Roadmaps 'n all that
we will know whether this is a great thing we should continue, or we should stick to our traditional laissez-faire style of project management. I figure that even if it really sucks, it wouldn't kill us to try it for one release cycle --- at the very worst, we'd make up lost time in future by no longer needing to waste bandwidth arguing about it. Would this be a core postgresql code roadmap or something a bit broader (contrib, custom types, GUI-ish stuff, utilities and what have you)? I think that we could at this time only expect things that would be submitted for core inclusion. The less cats to herd the better :) Joshua D. Drake Cheers, Steve ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Roadmaps 'n all that
Tom, I propose a modest experiment: for the 8.3 development cycle, let's try to agree (in the next month or so) on a roadmap of what major features should be in 8.3 and who will make each one happen. Well, I think the what is more important that the who -- we can switch whos if that's what it takes to make the what happen. Likely, we will have to. A year from now, we will know whether this is a great thing we should continue, or we should stick to our traditional laissez-faire style of project management. I figure that even if it really sucks, it wouldn't kill us to try it for one release cycle --- at the very worst, we'd make up lost time in future by no longer needing to waste bandwidth arguing about it. Great. I think we have some volunteers to put a tool online to track volunteers, specifications and status. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
