Josh Berkus writes:
> Basically reading a large table off disk does this:
> read some table while not processing
> process in cpu while not reading
> read some more table while not processing
> process some more in cpu while not reading
> etc.
> resulting in an I/O througput graph that looks like
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'd like to know some settings that we can use that will get Tru64
cleanly through the buildfarm set. If noone offers any, I propose that
we revert the getaddrinfo() test in configure and use our own on Tru64
until they do.
I have
On Friday 07 April 2006 16:10, Pavel Stehule wrote:
> Hello
>
> 1.11) How can I learn SQL?
> ...
> There is also a nice tutorial at
> http://www.intermedia.net/support/sql/sqltut.shtm, at
> http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, and
> at http://sqlcourse.com.
>
> fir
On 4/7/06, Josh Berkus wrote:
> So even on a single seq scan, parallel query
> execution would make a significant difference
> in performance, possibly as
> much as +75% on seq scans of large tables.
I've been looking at several commercial systems which employ dynamic
partitioning for sequential
Qingquing,
> First, I want to second Jonah's enthusiasm. This is very exciting!
Me, three! I didn't think this was ever going to come to Postgres absent
major corporate funding.
> This is really only a gut feeling for me (it can't be otherwise, since
> we can't yet test), but I think parallel
Hello
1.11) How can I learn SQL?
...
There is also a nice tutorial at
http://www.intermedia.net/support/sql/sqltut.shtm, at
http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, and
at http://sqlcourse.com.
first link is broken, second moved
Regards
Pavel Stehule
_
Can someone drop this puppy?
> -Original Message-
> From: System Administrator
> Sent: Thursday, April 06, 2006 11:49 PM
> To: [EMAIL PROTECTED]
> Subject: Undeliverable:Re: [GENERAL] stored proc vs sql query string
>
> Your message did not reach some or all of the inten
On 4/6/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
>
> ""Jonah H. Harris"" <[EMAIL PROTECTED]> wrote
> >
> > Great work! I had looked into this a little bit and came to the same
> > ideas/problems you did, but none of them seemed insurmountable at all.
> > I'd be interested in working with you o
"Nicolas Barbier" <[EMAIL PROTECTED]> writes:
> 2006/4/3, Tom Lane <[EMAIL PROTECTED]>:
>> AFAICS there are no circumstances, ever, in which update-in-place is
>> "safe". (No transaction can guarantee that it will commit.)
> Updates to row values that did not "escape" the currect transaction
> ye
On Fri, 7 Apr 2006, Martijn van Oosterhout wrote:
On Fri, Apr 07, 2006 at 05:05:12PM +0400, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README
One addition - some results of Gin testing is available:
http://www.sai.msu.su/~megera/oddmuse/index.cgi/GinTest
Oleg
On Fri, 7 Apr 2006, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.
2006/4/3, Tom Lane <[EMAIL PROTECTED]>:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > we're working on a prototype to reduce WAL I/O and index updates in a
> > large percentage of OLTP situations by employing an update-in-place
> > under *safe* conditions.
>
> AFAICS there are no circumstanc
On Fri, Apr 07, 2006 at 05:05:12PM +0400, Teodor Sigaev wrote:
> We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
> agree, we will commit it to HEAD branch.
>
> http://www.sigaev.ru/gin/gin.gz
> http://www.sigaev.ru/gin/README
Fantastic! I was thinking about this a while
to_timestamp is only for Oracle compatibility? I always thought it's some sort
of sql standard. What's the sql compliant way to do this?
Regards,
mario weilguni
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tom Lane
Gesendet: Freitag,
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will agree,
we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and initdb
README:
Gin for PostgreSQL
Gin stands for Generali
On 4/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Mario Weilguni <[EMAIL PROTECTED]> writes:
> > I think all except the first one should raise a warning, isn't it?
>
> to_timestamp (and friends) all seem to me to act pretty bizarre when
> faced with input that doesn't match the given format string.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Magnus Hagander
> Sent: 07 April 2006 13:00
> To: Jim C. Nasby
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Windows installer bugs (was: [BUGS]
> BUG #2374: Installation Error)
>
> > Now, it would certainly help if more people could actually help in
> > *answering* the bugs/questions that are posted :), but that's a
> > different question...
>
> Well, that's my primary concern. It seems that people aren't
> replying to bugs posted -bugs about the windows installer. I
>
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
???Sent: 06 April 2006 10:24To:
pgsql-hackers@postgresql.orgSubject: [HACKERS] pgadmin III's
Chinese simplified translations
i have continued the pgadmin III's Chinese simplified
translations,hope this
19 matches
Mail list logo
