> -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
"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 li
> -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
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.
> -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
"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,
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 04:49:10P
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-s
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 commandT
> -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 qsor
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
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
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 man
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 TRAN
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
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: R
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 cl
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 makin
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
> >
>
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
-
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 mentioni
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, sin
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 ca
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
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 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 shou
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 ser
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
http://archives.postgresql.org/pgsql-hacke
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) 359
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
> -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
31 matches
Mail list logo
