-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 15, 2005 6:24 PM
To: Dann Corbit
Cc: Qingqing Zhou; Greg Stark; Jim C. Nasby; Luke Lonergan; Neil
Conway;
Bruce Momjian; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Which qsort is used
Here's some results for a 2.5Ghz G5 and a 933Mhz G4
http://www.jefftrout.com/sort/
--
Jeff Trout [EMAIL PROTECTED]
http://www.jefftrout.com/
http://www.stuarthamm.net/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
The my email address is now working. If you sent an email on Monday
_and_ received a rejection email yesterday, please resend the email,
otherwise all email has been received.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610)
This archive:
http://archives.postgresql.org/pgsql-patches/2005-12/index.php
was last updated on wednesday, whereas the others:
http://archives.postgresql.org/pgsql-bugs/2005-12/index.php
http://archives.postgresql.org/pgsql-interfaces/2005-12/index.php
On Fri, 16 Dec 2005, Martijn van Oosterhout wrote:
This archive:
http://archives.postgresql.org/pgsql-patches/2005-12/index.php
http://svr5.postgresql.org/pgsql-patches/2005-12/index.php is the build
server for the archives, and is up to date ... so I'm going to guess that
the front-end
On Wed, 2005-12-14 at 21:27 -0500, Tom Lane wrote:
I've spent some time looking into how we can improve our planning of outer
joins.
Sounds good.
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
On Thu, 2005-12-15 at 09:25 -0500, Tom Lane wrote:
I did find some papers that talked about ways to push joins up and down
past aggregations and GROUP BY, but that's a problem for another day.
Yes, they seem like a good thing to get round to... the papers seem to
present them as fairly clear
On Fri, Dec 16, 2005 at 03:19:58PM -0400, Marc G. Fournier wrote:
On Fri, 16 Dec 2005, Martijn van Oosterhout wrote:
This archive:
http://archives.postgresql.org/pgsql-patches/2005-12/index.php
http://svr5.postgresql.org/pgsql-patches/2005-12/index.php is the build
server for the
Tom Lane wrote:
I've spent some time looking into how we can improve our planning of outer
joins. The current planner code slavishly follows the syntactic join
order, which can lead to quite bad plans. The reason it does this is that
in some cases altering the join order of outer joins can
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if the code is already able to transform right joins to left
joins, like
(A rightjoin B on (Pab)) = (B leftjoin A on (Pab))
Yeah, we already know that part. It's a freebie --- I didn't even
bother mentioning rightjoin in my post, since
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if the code is already able to transform right joins to left
joins, like
(A rightjoin B on (Pab)) = (B leftjoin A on (Pab))
Yeah, we already know that part. It's a freebie --- I didn't even
bother mentioning
Alvaro Herrera [EMAIL PROTECTED] writes:
Why the thing about the mergejoinable conditions then? Is that even
true?
There are some things that work off mergejoinable conditions, but the
equivalence of right and left join isn't one of them ...
regards, tom lane
On Fri, Dec 16, 2005 at 08:54:37PM +0100, Martijn van Oosterhout wrote:
On Fri, Dec 16, 2005 at 03:19:58PM -0400, Marc G. Fournier wrote:
On Fri, 16 Dec 2005, Martijn van Oosterhout wrote:
This archive:
http://archives.postgresql.org/pgsql-patches/2005-12/index.php
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I just read an article on LWN.net about the usage of self-modifying code
for selecting the optimum code for a given operation at run time.
That went out with hula hoops, I think. For sure the security
implications of making your
Hi,
recently someone show us this code in the spanish list...
BEGIN WORK;
INSERT INTO mitabla VALUES (1);
BEGIN TRANSACTION;
INSERT INTO mitabla VALUES (2);
INSERT INTO mitabla VALUES (3);
COMMIT TRANSACTION;
INSERT INTO mitabla VALUES (4);
ROLLBACK WORK;
this is clearly
I'm looking at a postgresql 7.3 database that has gotten rather bloated
in pg_statistic:
VACUUM verbose pg_statistic;
INFO: --Relation pg_catalog.pg_statistic--
INFO: Index pg_statistic_relid_att_index: Pages 4420; Tuples 1590:
Deleted 3789.
CPU 0.33s/0.03u sec elapsed 0.96 sec.
INFO:
Jaime Casanova [EMAIL PROTECTED] writes:
recently someone show us this code in the spanish list...
BEGIN WORK;
INSERT INTO mitabla VALUES (1);
BEGIN TRANSACTION;
INSERT INTO mitabla VALUES (2);
INSERT INTO mitabla VALUES (3);
COMMIT TRANSACTION;
INSERT INTO mitabla VALUES (4);
ROLLBACK
On Fri, 2005-12-16 at 17:36, Jaime Casanova wrote:
Hi,
recently someone show us this code in the spanish list...
BEGIN WORK;
INSERT INTO mitabla VALUES (1);
BEGIN TRANSACTION;
INSERT INTO mitabla VALUES (2);
INSERT INTO mitabla VALUES (3);
COMMIT TRANSACTION;
Robert Treat [EMAIL PROTECTED] writes:
I'm looking at a postgresql 7.3 database that has gotten rather bloated
in pg_statistic:
I am trying to figure out a way to shrink this down to something more
reasonable, with the caveat of not restarting the database server.
You haven't got too many
Luke Lonergan wrote:
Tom,
On 12/12/05 2:47 PM, Tom Lane [EMAIL PROTECTED] wrote:
As those results suggest, there can be huge differences in sort
performance depending on whether the input is random, nearly sorted,
nearly reverse sorted, possesses many equal keys, etc. It would be very
On Fri, 16 Dec 2005, Bruce Momjian wrote:
At this point, I think we have done enough testing on enough platforms
to just use port/qsort on all platforms in 8.2. It seems whenever
someone tries to improve the BSD qsort, they make it worse.
Not necessariliy true. Dann Corbit sent me an
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Qingqing Zhou
Sent: Friday, December 16, 2005 5:14 PM
To: Bruce Momjian
Cc: Luke Lonergan; Tom Lane; Neil Conway; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Which qsort is
Volkan YAZICI wrote:
I prepared a patch for Have COPY return the number of rows
loaded/unloaded? TODO. (Sorry for disturbing list with such a simple
topic, but per warning from Bruce Momjian, I send my proposal to -hackers
first.)
I used the appending related information to commandTag
Luke Lonergan wrote:
Qingqing,
On 12/15/05 6:33 PM, Qingqing Zhou [EMAIL PROTECTED] wrote:
Thanks for Greg let me take a second look at qsortB.c - there is
paste-and-copy error there, so when it perform recursive sort, it calls
glibc's qsort ... Really sorry, and feel a little bit gun-shy
Good idea, TODO updated:
* Flush cached query plans when the dependent objects change or
when the cardinality of parameters changes dramatically
---
Jim C. Nasby wrote:
On Tue, Dec 13, 2005 at
Dann Corbit [EMAIL PROTECTED] writes:
Both of them are modified versions of Bentley's sort algorithm.
Jon Bentley of Bell Labs? Small world ... he was my thesis adviser
for awhile when he was at CMU. He's a good algorithms man, for sure.
I just added the in-order check to both of them, and
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, December 16, 2005 9:03 PM
To: Dann Corbit
Cc: Qingqing Zhou; Bruce Momjian; Luke Lonergan; Neil Conway; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Re: Which qsort is used
Dann Corbit [EMAIL PROTECTED]
On Sat, 17 Dec 2005, Dann Corbit wrote:
The benchmarks say that they (order checks) are a good idea on average
for ordered data, random data, and partly ordered data.
I interpret that in linux, 500 seems a divide for qsortpdq. Before
that number, it wins, after that, bsd wins more. On
-Original Message-
From: Qingqing Zhou [mailto:[EMAIL PROTECTED]
Sent: Friday, December 16, 2005 10:13 PM
To: Dann Corbit
Cc: Tom Lane; Bruce Momjian; Luke Lonergan; Neil Conway; pgsql-
[EMAIL PROTECTED]
Subject: RE: [HACKERS] Re: Which qsort is used
On Sat, 17 Dec 2005, Dann
Dann Corbit [EMAIL PROTECTED] writes:
I've still got a problem with these checks; I think they are a net
waste of cycles on average.
The benchmarks say that they (order checks) are a good idea on average
for ordered data, random data, and partly ordered data.
There are lies, damn lies, and
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, December 16, 2005 10:41 PM
To: Dann Corbit
Cc: Qingqing Zhou; Bruce Momjian; Luke Lonergan; Neil Conway; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Re: Which qsort is used
Dann Corbit [EMAIL PROTECTED]
31 matches
Mail list logo
