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
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
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
On Tue, 2008-09-09 at 16:26 -0400, Tom Lane wrote:
That's probably not good because it *looks* like we support the syntax,
but in fact produce non-spec-compliant results. I think it might be
better if we threw an error.
Definitely. If we accept SQL Standard syntax like this but then not do
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
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via
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, I
wonder is there any official statements about this, because it will affect our
plane of using PostgreSQL as an
On Tue, Sep 09, 2008 at 07:59:49PM +0800, Amber wrote:
I read something from
http://monetdb.cwi.nl/projects/monetdb/SQL/Benchmark/TPCH/index.html
Given that the point of that study is to prove something about
performance, one should be leery of any claims based on an out of the
box comparison.
@postgresql.org
Subject: Re: [GENERAL] PostgreSQL TPC-H test result?
On Tue, Sep 09, 2008 at 07:59:49PM +0800, Amber wrote:
I read something from
http://monetdb.cwi.nl/projects/monetdb/SQL/Benchmark/TPCH/index.html
Given that the point of that study is to prove something about
performance
On Tue, Sep 9, 2008 at 7:06 AM, Amber [EMAIL PROTECTED] wrote:
Yes, we don't care about the performance results, but we do care about the
point that PostgreSQL can't give the correct results of TPC-H queries.
It would be nice to know about the data, queries, and the expected
results of their
On Tue, Sep 9, 2008 at 10:06 AM, Amber [EMAIL PROTECTED] wrote:
Yes, we don't care about the performance results, but we do care about the
point that PostgreSQL can't give the correct results of TPC-H queries.
PostgreSQL, at least in terms of the open source databases, is
probably your best
On Tue, Sep 09, 2008 at 10:06:01PM +0800, Amber wrote:
Yes, we don't care about the performance results, but we do care about the
point that PostgreSQL can't give the correct results of TPC-H queries.
I have never heard a reputable source claim this. I have grave doubts
about their claim:
On Tuesday 09 September 2008 10:06:01 Amber wrote:
From: Andrew Sullivan [EMAIL PROTECTED]
Sent: Tuesday, September 09, 2008 8:39 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] PostgreSQL TPC-H test result?
On Tue, Sep 09, 2008 at 07:59:49PM +0800, Amber wrote:
I read
My 02c,
Pg does itself no favours by sticking with such pessimistic defaults, and a
novice user wanting to try it out will find tweaking the pg configuration files
for performance quite complicated.
Given the general increase in typical hardware specs these days, perhaps the
default pg specs
On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote:
Given the general increase in typical hardware specs these days,
perhaps the default pg specs could be set for higher spec systems?
Given the default shmem configuration on operating systems these days,
upping the default will likely
On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote:
Pg does itself no favours by sticking with such pessimistic
defaults, and a novice user wanting to try it out will find tweaking
the pg configuration files for performance quite complicated.
You do know that at install time, Pg does
Robert Treat [EMAIL PROTECTED] writes:
http://www.it.iitb.ac.in/~chetanv/personal/acads/db/report_html/node10.html.
It isn't terribly informative, but it doesindicate one thing, someone else
was able to run query #6 correctly, while the above site claims it returns an
error. Now when I look
On Tue, Sep 9, 2008 at 2:07 PM, Andrew Sullivan [EMAIL PROTECTED] wrote:
. . . your figuring here is indeed simplistic. Every day I see
requests for help from people who have followed the rule of thumb 1/4
of memory for shared_buffers, except that they're also running
apache+jakarta, MySQL,
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
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
On Tue, Sep 9, 2008 at 3:37 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote:
Given the general increase in typical hardware specs these days,
perhaps the default pg specs could be set for higher spec systems?
Given the default
20 matches
Mail list logo
