fixing some typos, sorry is late...
> > i am trying to download the windows version since 3 hours ago and just
> > get an error page no matters if i try the FTP browser, ftp mirrors or
> > bittorrent
> >
>
MOre on this, i was able to download from bittorrent when i manually
paste the url and remov
On 3/11/06, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i am trying to download the windows version since 3 hours ago and just
> get an error page no matters if i try the FTP browser, ftp mirrors or
> bittorrent
>
MOre on this, i was able to download from bittorrent when i manually
paste t
Hi,
i am trying to download the windows version since 3 hours ago and just
get an error page no matters if i try the FTP browser, ftp mirrors or
bittorrent
--
regards,
Jaime Casanova
"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wron
I wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> samples %symbol name
>> 350318533 98.8618 mergepreread
>> 9718220.2743 tuplesort_gettuple_common
>> 4136740.1167 tuplesort_heap_siftup
> I don't have enough memory to really reproduce this, but I've come close
> eno
On fös, 2006-03-10 at 16:51 -0500, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > One key difference would be that synonyms track schema updates, like
> > adding a column, to the referenced object that a view would not.
>
> That raises a fairly interesting point, actually. What wou
Kris Jurka <[EMAIL PROTECTED]> writes:
> One key difference would be that synonyms track schema updates, like
> adding a column, to the referenced object that a view would not.
That raises a fairly interesting point, actually. What would you expect
to happen here:
CREATE TABLE foo ...;
Matteo Beccati wrote:
> Bruce Momjian ha scritto:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> Great.
Stefan,
On 3/10/06 12:23 PM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
> wrong(or rather extremely optimistic) the array itself only has two
> (redundant) FC-loops(@2GB )to the attached expansion chassis. The array
> has 2 active/active controllers (with a failover penalty) with two host
On Thu, 9 Mar 2006, Jonah H. Harris wrote:
2) For my comprehension, what's the difference between a SYNONYM and a
single-object (possibly updatable) view?
Not a whole lot actually. If we had updateable views, I'd suggest that
people change their create synonym syntax to create view.
One
Luke Lonergan wrote:
> Stefan,
>
> On 3/10/06 11:48 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
>
>
>>2 HBAs in the server, 2x2 possible paths to each LUN.
>>6 disks for the WAL and 12 disks for the data
>
>
> So - you have 18 disks worth of potential bandwidth, not factoring loss du
On Mar 10, 2006, at 11:54 AM, Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
3. vacuuming this table - it turned out that VACUUM FULL is
completly
unusable on a table(which i actually expected before) of this
size not
only to the locking involved but rather due to a gigan
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> samples %symbol name
> 350318533 98.8618 mergepreread
> 9718220.2743 tuplesort_gettuple_common
> 4136740.1167 tuplesort_heap_siftup
I don't have enough memory to really reproduce this, but I've come close
enough that I believe
Stefan,
On 3/10/06 11:48 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
> 2 HBAs in the server, 2x2 possible paths to each LUN.
> 6 disks for the WAL and 12 disks for the data
So - you have 18 disks worth of potential bandwidth, not factoring loss due
to RAID. That's roughly 18 * 60 = 1,
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> 3. vacuuming this table - it turned out that VACUUM FULL is completly
>>> unusable on a table(which i actually expected before) of this size not
>>> only to the locking involved but rather due to a gigantic memory
>>> requirement and unbelievable
Luke Lonergan wrote:
> Stefan,
>
> On 3/10/06 9:40 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
>
>
>>I will summarize some of the just in case somebody is interested:
>
>
> I am!
heh - not surprised :-)
>
>
>>-> table used has 5 integer columns non-indexed during the loads
>>-> h
Just curious, but how do ppl come to Canada as tourists from other
countries? I don't imagine they need to be "invited" by a Canadian, do
they?
On Fri, 10 Mar 2006, Josh Berkus wrote:
Alvaro,
Thanks for the pointers. I'm looking forward to finding somebody who
wants to "sponsor" me on t
On Friday 10 March 2006 07:53, Bruce Momjian wrote:
> Jan Wieck wrote:
> > On 3/8/2006 5:31 PM, Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > >> Bruce Momjian wrote:
> > >> > Log Message:
> > >> > ---
> > >> > Remove Christof Petig copyright on include file, per author request.
> > >
Stefan,
On 3/10/06 9:40 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
> I will summarize some of the just in case somebody is interested:
I am!
> -> table used has 5 integer columns non-indexed during the loads
> -> hardware is a Dual Opteron 280 with 4 [EMAIL PROTECTED],4GHz and 16GB R
Alvaro,
> Thanks for the pointers. I'm looking forward to finding somebody who
> wants to "sponsor" me on this issue ... or maybe get me a passport from
> the Holy See.
>
> > The other "pointy bit" is that the letter of invitation needs to
> > indicate the inviter's relationship to the person bei
Hi all!
During my testing of large work_mem and maintainence_work_mem setting
wrt to CREATE INDEX and sorting I encountered a number of things wrt to
doing various operations on such a large table (about 106GB on disk with
no dead tuples).
I will summarize some of the just in case somebody is inte
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>>> I'll look into it, but I was already wondering if we shouldn't bound
>>> the number of tapes somehow. It's a bit hard to believe that 28000
>>> tapes is a sane setting.
>>
>> Well, since they are not actually tapes, why not?
> I wonde
On 3/10/2006 10:53 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 3/8/2006 5:31 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>> > Log Message:
>> > ---
>> > Remove Christof Petig copyright on include file, per author request.
>>
>> Huh, I thought what he actua
> > I'll look into it, but I was already wondering if we shouldn't bound
> > the number of tapes somehow. It's a bit hard to believe that 28000
> > tapes is a sane setting.
>
> Well, since they are not actually tapes, why not?
I wonder what the OS does when we repeatedly open and close those
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> samples %symbol name
> 350318533 98.8618 mergepreread
> 9718220.2743 tuplesort_gettuple_common
> 4136740.1167 tuplesort_heap_siftup
I'm not immediately seeing why mergepreread would have such a problem
with lots of tapes. Coul
Jan Wieck wrote:
> On 3/8/2006 5:31 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >> > Log Message:
> >> > ---
> >> > Remove Christof Petig copyright on include file, per author request.
> >>
> >> Huh, I thought what he actually told was that the file was r
On 3/8/2006 5:31 PM, Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
> Log Message:
> ---
> Remove Christof Petig copyright on include file, per author request.
Huh, I thought what he actually told was that the file was released
under BSD license. Maybe I missed it, but
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2006-03-10 at 09:31 -0500, Tom Lane wrote:
>> I'll look into it, but I was already wondering if we shouldn't bound the
>> number of tapes somehow. It's a bit hard to believe that 28000 tapes is
>> a sane setting.
> I thought you had changed the me
On Fri, 2006-03-10 at 09:31 -0500, Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f
> > LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec
> > elapsed 32.43 sec
> > LOG: finished wri
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f
>>LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec
>>elapsed 32.43 sec
>>LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.8
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f
> LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec
> elapsed 32.43 sec
> LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.85u sec elapsed
> 381
> > > Two pass will create the count of subfiles proportional to:
> > > Subfile_count = original_stream_size/sort_memory_buffer_size
> > >
> > > The merge pass requires (sizeof record * subfile_count) memory.
> >
> > That is true from an algorithmic perspective. But to make the merge
> > effici
Bruce Momjian ha scritto:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Great. I would just like to remind that Tom said:
Charlie,
I'm currently working on a similar solution (it's true I'm only in the
thinking phase). I don't have too much time to spend on it (~few hours
per week, on the train during commuting), so it's not progressing too
fast...
Nevertheless, I would like to do a first proof-of-concept version in
--On Freitag, März 10, 2006 09:43:04 + Richard Huxton
wrote:
I'd certainly be interested in having auto-updatable views in 8.2 - even
if it was only for the simplest of cases. If I can be of any help testing
etc. let me know.
Yeah, that would be cool. I've sent the latest patch to -h
Jaime Casanova wrote:
On 3/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Josh Berkus writes:
Eh? I thought that it was just syntatic sugar that was missing. I've
built lots of updatable views manually; I don't see what's difficult about
it.
I think you'll find that corner cases like inserts in
--On Donnerstag, März 09, 2006 17:23:11 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
(BTW, there was some work being done on updatable views, but I think
it's stalled. I suspect the reason is that our current rule system
is just too odd to support updatable views reasonably. I've been
wonderi
Hi folks,
Please find attached a patch that implements SQL92-compatible updatable
views. The patch introduces new semantics into the rule system: implicit
and explicit rules. Implicit rules are created to implement updatable views:
_INSERT
_NOTHING_INSERT (unconditional DO INSTEAD NOTHING rul
On Wed, Mar 08, 2006 at 10:34:38PM -0800, Ben Chelf wrote:
> On 3/8/06, Josh Berkus wrote:
>
> >Actually, I thougth that Neil/eDB did this with their copy. Is
> > there any way to get a copy of that "training configuration"?
>
>
> Just to jump in on this thread, we can absolutely configure
On Fri, Mar 10, 2006 at 09:57:28AM +0100, Zeugswetter Andreas DCP SD wrote:
>
> > Two pass will create the count of subfiles proportional to:
> > Subfile_count = original_stream_size/sort_memory_buffer_size
> >
> > The merge pass requires (sizeof record * subfile_count) memory.
>
> That is true
Hello,
I want do sql wrap for woid plpgsql function. But void SQL function must not
finish SELECT cmd. I don't know any others command which I can use.
Can You help me?
Thank You
Pavel Stehule
_
Najdete si svou lasku a nove prate
> Two pass will create the count of subfiles proportional to:
> Subfile_count = original_stream_size/sort_memory_buffer_size
>
> The merge pass requires (sizeof record * subfile_count) memory.
That is true from an algorithmic perspective. But to make the
merge efficient you would need to have en
41 matches
Mail list logo
