Greg Smith <[EMAIL PROTECTED]> writes:
> Quoting from Lewine's "POSIX Programmer's Guide":
> "After a write() to a regular file has successfully returned, any
> successful read() from each byte position in the file that was modified by
> that write() will return the data that was written by the
"Robins Tharakan" <[EMAIL PROTECTED]> writes:
> Would it fine to consider that an UPDATE query that found no records to
> update is (performance wise) the same as a SELECT query with the same WHERE
> clause ?
> As in, does an UPDATE query perform additional overhead even before it finds
> the reco
Coming to think of it.
Would it fine to consider that an UPDATE query that found no records to
update is (performance wise) the same as a SELECT query with the same WHERE
clause ?
As in, does an UPDATE query perform additional overhead even before it finds
the record to work on ?
*Robins*
On T
Hi, thanks for the quick reply.
> In general I would recommend that you benchmark them using
> as-close-to-real load as possible again as-real-as-possible data.
I am running a benchmark with around 900,000 odd records (real-load on
the live machine :o ) ... should show hopefully some good bench
Stephen Frost wrote
> * Ravi Chemudugunta ([EMAIL PROTECTED]) wrote:
> > Which version is faster?
>
> In general I would recommend that you benchmark them using
> as-close-to-real load as possible again as-real-as-possible data.
>
> > Does the exception mechanism add any overhead?
>
> Yes, using
* Ravi Chemudugunta ([EMAIL PROTECTED]) wrote:
> Which version is faster?
In general I would recommend that you benchmark them using
as-close-to-real load as possible again as-real-as-possible data.
> Does the exception mechanism add any overhead?
Yes, using exceptions adds a fair bit of overhea
Hello,
I have a typical many to many join table, in this instance it is
capturing the multiplicity described as "one person can have many
rooms and one room can have many persons". Further the join expresses
where in the room the person is sitting, a seat number. I am creating
a function to abst
On Mon, 31 Mar 2008, James Mansion wrote:
Is it correct that POSIX requires that the updates to a single
file are serialised in the filesystem layer?
Quoting from Lewine's "POSIX Programmer's Guide":
"After a write() to a regular file has successfully returned, any
successful read() from eac
Mark Mielke wrote:
Is there anything in POSIX that seems to suggest this? :-) (i.e. why
are you going under the assumption that the answer is yes - did you
read something?)
Perhaps it was just this:
http://kevinclosson.wordpress.com/2007/01/18/yes-direct-io-means-concurrent-writes-oracle-doe
I don't believe POSIX has any restriction such as you describe - or if
it does, and I don't know about it, then most UNIX file systems (if
not most file systems on any platform) are not POSIX compliant.
I suspect that indeed there are two different issues here in that the
file mutex relates
Mark Mielke wrote:
Is there anything in POSIX that seems to suggest this? :-) (i.e. why
are you going under the assumption that the answer is yes - did you
read something?)
It was something somewhere on the Sun web site, relating to tuning Solaris
filesystems. Or databases. Or ZFS. :-(
Need
James Mansion wrote:
(Declaration of interest: I'm researching for a publication
on OLTP system design)
I have a question about file writes, particularly on POSIX.
This arose while considering the extent to which cache memory
and command queueing on disk
drives can help improve performance.
Is
(Declaration of interest: I'm researching for a publication
on OLTP system design)
I have a question about file writes, particularly on POSIX.
This arose while considering the extent to which cache memory
and command queueing on disk
drives can help improve performance.
Is it correct that POSIX
Hi! I've got the following statement:
SELECT DISTINCT sub.os,
COUNT(sub.os) as total
FROM (
SELECT split_part(system.name, ' ', 1) as os
FROM system, attacks
WHERE 1 = 1
AND timestamp >= 1205708400
AND timestamp <= 120631320
Le Monday 31 March 2008, Martin Kjeldsen a écrit :
> Hello,
>
> I'm sorry if this has been discussed before, I couldn't find a discussion
> about this problem.
>
> I've done the same query on a 8.2.5 database. The first one is prepared
> first and the other is executed directly.
>
> I understand wh
Hello,
I'm sorry if this has been discussed before, I couldn't find a discussion about
this problem.
I've done the same query on a 8.2.5 database. The first one is prepared first
and the other is executed directly.
I understand why the there is such a great difference between the two ways of
16 matches
Mail list logo
