I've been waiting for atleast one more person to sign up for the training
so OTG can confirm this class down there, they said that some of the
internal hackers had requested the course out there, so I wanted to ping
everyone here. I know, kinda off topic and all, but the event is coming up
soo
The platypus model he has has an external PSU. The external PSU can be
easily plugged into an UPS. Thus if the main system is shut down as long
as the UPS lives and/or there is power otherwise to the external PSU, the
card will keep the data.
--On Thursday, March 06, 2003 11:16 PM +0200 Hannu
Which is whay you RTFM ;)
--On Friday, June 21, 2002 10:10 PM -0400 David Ford
<[EMAIL PROTECTED]> wrote:
> On the other hand, I like hints on how to do things better ;)
>
> David
>
> Thomas Lockhart wrote:
>
>>> So, is you vote for or against the elog(NOTICE)?
>>>
>>>
>>
>> OK, if we are still
eliminate these byt adding another weight factor (IE last time we did
this it took X amount of time, and we estimated Y, so lets try it this
way instead).
Unfortunately I'm a bit too pressed for time looking for a job to
continue pursuing this research any furt
son I
can come up with.
*quietly installs an rm -rf trigger if tom does any I/O on the has files
outside of the compiler* This is for your own safety Tom... Well that
and our amusement :)
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>> I don't know a
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>>[ on hash vs btree indexing ]
>>Most of the time until the btree gets deep they are nearly equivalent.
>>When the tree ends up becoming many levels deep it can take longer to
>>walk th
A Block-sized read will not be rboken up. But if you're reading ina
size bigger than the underlying systems block sizes then it can get
broken up.
So yes a sequential read will get broken up. A single read request for
a block may or may not get broken up. If you're freading with set block
Tom Lane wrote:
>Curt Sampson <[EMAIL PROTECTED]> writes:
>
>>Grabbing bigger chunks is always optimal, AFICT, if they're not
>>*too* big and you use the data. A single 64K read takes very little
>>longer than a single 8K read.
>>
>
>Proof?
>
I contend this statement.
It's optimal to a point.
Bruce Momjian wrote:
>Hiroshi, we need a psql solution too. People are feeding query files
>into psql all the time and we should have an appropriate behavior for
>them.
>
>I now understand your point that from a ODBC perspective, you may not
>want SETs rolled back and you would rather ODBC han
Hiroshi Inoue wrote:
>Michael Loftis wrote:
>
>>Hiroshi Inoue wrote:
>>
>>>What's wrong with it ? The insert command after *rollback*
>>>would fail. It seems the right thing to me. Otherwise
>>>the insert command would try to append the data o
Hiroshi Inoue wrote:
>What's wrong with it ? The insert command after *rollback*
>would fail. It seems the right thing to me. Otherwise
>the insert command would try to append the data of the
>table t1 to itself. The insert command is for copying
>schema1.t1 to foo.t1 in case the previous create
Vote number 1 -- ROLL BACK
Bruce Momjian wrote:
>OK, would people please vote on how to handle SET in an aborted
>transaction? This vote will allow us to resolve the issue and move
>forward if needed.
>
>In the case of:
>
> SET x=1;
> BEGIN;
> SET x=2;
> query_that_abort
The benchmarks will depend mostly on the depth of the Btree. Hashes
will be markedly faster only in the case(s) where descending into the
tree to produce a matching leaf node would take longer than walking to
the appropriate item in a hash.
Most of the time until the btree gets deep they are
Thomas Lockhart wrote:
>>>But I do override some parameters in my Makefile.custom:
>>>CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
>>>
>>If you use -O0 then you miss most of the interesting warnings.
>>
>
>?? Not in this case. afaik -O0 suppresses most optimizations (and hence
>does not reorder instru
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>>Also I'd also like to know if there is a way to get the planner to burp
>>out all the possible plans it considered before selecting a final plan
>>or do I need to do a little surgery to
cting a final plan
or do I need to do a little surgery to get that done?
TIA guys!
Michael Loftis
BTW I'm not masochistic, I'm just out of work and BORED :)
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please se
Hiroshi Inoue wrote:
>Tom Lane wrote:
>
>>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>>
>>>I don't think this is *all* *should be* or *all
>>>or nothing* kind of thing. If a SET variable has
>>>its reason, it would behave in its own right.
>>>
>>Well, we could provide some kind of escape hatch t
483648 bytes read in 1739.773354 seconds
1739.78 real 4.41 user36.36 sys
TESTS COMPLETED
Thu Apr 18 11:43:15 PDT 2002
Michael Loftis wrote:
> Numbers being run on a BSD box now...
>
> FreeBSD 4.3-p27 512MB RAM 2xPiii600 Xeon ona 4 disk RAID 5 ARRAY on a
> dedi
n Unix standard in
this regard...
This will make it usable for much larger test files.
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>>Somethings wrong with the random numbers from the sun... re-run them,
>>that first sample is insane Caching looks li
Somethings wrong with the random numbers from the sun... re-run them,
that first sample is insane Caching looks like it's affecctign your
results alot...
Mark Pritchard wrote:
>I threw together the attached program (compiles fine with gcc 2.95.2 on
>Solaris 2.6 and egcs-2.91.66 on RedHat
Finally someone writes down whats been itching at my brain for a while.
In a multi-tasking system it's always cheaper to fetch less blocks, no
matter where they are. Because, as you said, it will end up more or
less random onf a system experiencing a larger number of queries.
mlw wrote:
>Bru
Tom Lane wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>>I have added this to the TODO list, with a question mark. Hope this is
>>OK with everyone.
>>
>
>>o Abort SET changes made in aborted transactions (?)
>>
>
>Actually, I was planning to make only search_path act that way, be
Oliver Elphick wrote:
>On Wed, 2002-04-17 at 06:51, mlw wrote:
>
>>I just think there is sufficient evidence to suggest that if a DBA creates an
>>index, there is strong evidence (better than statistics) that the index need be
>>used. In the event that an index exists, there is a strong indicat
My opinion.
Expose some of the cost factors via run-time settings (or start-time
settings).
This would allow those who wanted to 'tweak' the planner to do so and
those that felt the defaults were fine or didn't know to leave them alone.
Comments?
---(end of broadca
Am I right, or did I miss
something? (wouldn't be the first time I missed something)... Right
now the planner seems to think that index queries are more expensive
with a larger width than doing a seqscan on (possibly) more rows with a
narrower width.
Michael Loftis wrote:
> Readin
Reading all of this discussion lately about how the planner seems to
prefer seqscan's in alot of places where indexes would be better starts
making me wonder if some of the assumptions or cals made to figure costs
are wrong...
Anyone have any ideas?
Louis-David Mitterrand wrote:
>On Tue, Ap
Lamar Owen wrote:
[EMAIL PROTECTED]">
The low-latency and preemptible patches are not meant for performancegains, but for responsiveness, and are not designed to be used in servers,only in workstations/desktops.
ISTM that improving interactive performance would also improve mul
Patents are as much designed to confuse and dissuade someone from using
something as they are to patent something. Reading a patent is often
harder than killing the nearest chicken, strewing it's entrails allover
the yard, and then trying to make some sense of it.
Justin Clift wrote:
>Hannu
Heh pardon me but...
I was under the impression that for a transaction either all commands
succeed or all commands fail, atleast according to everything I've ever
read. So followign that all SETs done within the scope of a
BEGIN/COMMIT pair should only take effect if the whole set finishes, i
29 matches
Mail list logo
