| Id | date | Message |
|---|---|---|
| 2008-09-10 09:16:54.0 | ||
| 150099 | 2008-09-10 09:16:54.0 | On Tue, Sep 09, 2008 at 05:42:50PM -0400, Greg Smith wrote: > > While some of the MonetDB bashing in this thread was unwarranted, What bashing? I didn't see any bashing of them. A -- Andrew Sullivan noway@spam.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |
| 151021 | 2008-09-11 17:56:00.0 | Tom Lane wrote: >> interval '1' year. > > ...is SQL spec syntax, but it's not fully implemented in Postgres... > > Or someone could try to make it work, but given that no one has taken > the slightest interest since Tom Lockhart left the project, I wouldn't > hold my breath waiting for that. I have interest. For 5 years I've been maintaining a patch for a client that allows the input of ISO-8601 intervals (like 'P1YT1M') rather than the nonstandard shorthand ('1Y1M') that postgresql supports[1]. I'd be interested in working on this. Especially if supporting SQL standard interval syntax could improve the chances of getting my ISO-8601-interval-syntax replacing nonstandard-postgres-shorthand-intervals patch accepted again, I'd be quite happy work on it. Tom in 2003 said my code looked cleaner than the current code[2], and the patch was accepted[3] for a while before being rejected - I believe because Peter said he'd like to see the SQL standard intervals first. I see it's still a TODO, though. > the grammar supports it but the info doesn't get propagated to > interval_in, and interval_in wouldn't know what to do even if it did > have the information that there was a YEAR qualifier after the literal. Any hints on how best to propagate the needed info from the grammar? Or should it be obvious to me from reading the code? [1] http://archives.postgresql.org/pgsql-patches/2003-09/msg00119.php [2] http://archives.postgresql.org/pgsql-patches/2003-09/msg00121.php [3] http://archives.postgresql.org/pgsql-patches/2003-12/msg00253.php Ron Mayer (formerly noway@spam.com who posted those ISO-8601 interval patches) -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |
| 151032 | 2008-09-11 18:17:37.0 | Ron Mayer wrote: > Tom Lane wrote: >> Or someone could try to make it work, but given that no one has taken >> the slightest interest since Tom Lockhart left the project, I wouldn't >> hold my breath waiting for that. > > I have interest. For 5 years I've been maintaining a patch for a client Doh. Now that I catch up on emails I see Tom has a patch in a different thread. I'll follow up there... -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |
| 151091 | 2008-09-11 22:36:45.0 | Moving this thread to Performance alias as it might make more sense for folks searching on this topic: Greg Smith wrote: > On Tue, 9 Sep 2008, Amber wrote: > >> I read something from >> http://monetdb.cwi.nl/projects/monetdb/SQL/Benchmark/TPCH/index.html >> saying that PostgreSQL can't give the correct result of the some >> TPC-H queries > > Jignesh Shah at Sun ran into that same problem. It's mentioned > briefly in his presentation at > http://blogs.sun.com/jkshah/entry/postgresql_east_2008_talk_postgresql > on pages 26 and 27. 5 of the 22 reference TCP-H queries (4, 5, 6, 10, > 14) returned zero rows immediately for his tests. Looks like the > MonetDB crew is saying it does that on queries 4,5,6,10,12,14,15 and > that 20 takes too long to run to generate a result. Maybe 12/15/20 > were fixed by changes in 8.3, or perhaps there were subtle errors > there that Jignesh didn't catch--it's not like he did a formal > submission run, was just kicking the tires. I suspect the difference > on 20 was that his hardware and tuning was much better, so it probably > did execute fast enough. I redid a quick test with the same workload on one of my systems with SF 10 which is about 10GB (I hope it comes out properly displayed) Jignesh From Monet (8.3T/8.2.9) Q Time PG8.3.3 Time PG8.2.9 Ratio 1 429.01 510 0.84 2 3.65 54 0.07 3 33.49 798 0.04 4 6.53 Empty 35 (E) 0.19 5 8.45 Empty 5.5(E) 1.54 6 32.84 Empty 172 (E) 0.19 7 477.95 439 1.09 8 58.55 251 0.23 9 781.96 2240 0.35 10 9.03 Empty 6.1(E) 1.48 11 3.57 Empty 25 0.14 12 56.11 Empty 179 (E) 0.31 13 61.01 140 0.44 14 30.69 Empty 169 (E) 0.18 15 32.81 Empty 168 (E) 0.2 16 23.98 115 0.21 17 Did not finish Did not finish 18 58.93 882 0.07 19 71.55 218 0.33 20 Did not finish Did not finish 21 550.51 477 1.15 22 6.21 Did not finish All time is in seconds (sub seconds where availabe) Ratio > 1 means 8.3.3 is slower and <1 means 8.3.3 is faster My take on the results: * I had to tweak the statement of Q1 in order to execute it. (TPC-H kit does not directly support POSTGRESQL statements) * Timings with 8.3.3 and bit of tuning gives much better time overall This was expected (Some queries finish in 7% of the time than what MonetDB reported. From the queries that worked only Q7 & Q21 seem to have regressed) * However Empty rows results is occuring consistently (Infact Q11 also returned empty for me while it worked in their test) Queries: 4,5,6,10,11,12,14,15 (ACTION ITEM: I will start separate threads for each of those queries in HACKERS alias to figure out the problem since it looks like Functional problem to me and should be interesting to hackers alias) * Two queries 17,20 looks like will not finish (I let Q17 to run for 18 hrs and yet it had not completed. As for Q20 I killed it as it was approaching an hour.) (ACTION ITEM: Not sure whether debugging for these queries will go in hackers or perform alias but I will start a thread on them too.) * Looks like bit of tuning is required for Q1, Q7, Q9, Q21 to improve their overall time. Specially understanding if PostgreSQL is missing a more efficient plan for them. (ACTION ITEM: I will start separate threads on performance alias to dig into those queries) I hope to start separate threads for each queries so we can track them easier. I hope to provide explain analyze outputs for each one of them and lets see if there are any problems. Feedback welcome on what you want to see for each threads. Regards, Jignesh -- Jignesh Shah http://blogs.sun.com/jkshah Sun Microsystems,Inc http://sun.com/postgresql -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |