-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Somehow, "prevent infinite loops" doesn't seem like justification for
> "refuse to deal with a situation that the software creates automatically".
> They ought to be willing to burrow more than one level ... see any Unix
> kernel's tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xiao Meng wrote:
> Hi, hackers. Here is some test I run on a bigger set.
>
> The time of the two index is
> btree: 1/0.174700=5.00250125
> hash-patch: 1/0.199900=5.724098
Just to bring it to attention of everybody:
btree: 1/0.174700=5.724098
hash-pat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> ERROR: database "%s" is being accessed by other users
> DETAIL: There are %d session(s) and %d prepared transaction(s) using the
> database.
>
> I'm aware that this phrasing might not translate very nicely ... anyone
> have a sugges
ad-only slave
192.168.0.11 SYNCHRONOUS APPLY-- read-only slave
192.168.0.20 SYNCHRONOUS SHIP -- backup-server
192.168.0.21 SYNCHRONOUS SHIP -- backup-server
192.168.0.30 SYNHCRONOUS FSYNC -- backup-server with fast disks
;
and then something like
syn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
> An array subscript expression will return null if either the array itself
> or any of the subscript expressions are null. Also, null is returned
> if a subscript is outside the array bounds (this case does not raise an
>
ery unfortunate.
I still got the lower solid-state latency, but the raid did not help.
Regards,
Jens-Wolfhard Schicke
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHUwM7zhchXT4RR5ARAsziAJ9qm/c8NuaJ+HqoJo9Ritb2t92fRwCgnF9J
r5YU/Fa0mNYG7YXed4QW7K4=
=Mvyj
-END
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Stark wrote:
> But that requires a) dealing with the problem of the parent table which has no
> constraints and b) an efficient way to prove that constraints don't overlap
> and order them properly. The latter looks like an O(n^2) problem to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shreya Bhargava wrote:
> "Note that the bottom line for the problems with hash indexes is that the
> current implementation doesn't offer any advantages over btree indexes. Hash
> indexes need to be not only as good of a choice as btree indexes but
> s
More random thoughts:
- Hash-Indices are best for unique keys, but every table needs a new hash
key, which means one more random page access. Is there any way to build
multi-_table_ indices? A join might then fetch all table rows with a given
unique key after one page fetch for the combined in
--On Samstag, September 08, 2007 18:56:23 -0400 Mark Mielke
<[EMAIL PROTECTED]> wrote:
Kenneth Marshall wrote:
Along with the hypothetical performance
wins, the hash index space efficiency would be improved by a similar
factor. Obviously, all of these ideas would need to be tested in
various work
--On Dienstag, Januar 30, 2007 23:24:40 + Simon Riggs
<[EMAIL PROTECTED]> wrote:
Basically what I see here is a whole lot of work and new executor
infrastructure for something that will be a win in a very narrow
use-case and a significant loss the rest of the time. I think there
are more pro
--On Dienstag, August 15, 2006 16:33:27 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
I'm tempted to suggest that the RETURNING commands might need to be
separate rule events, and that to support this you'd need to write
an additional rule:
CREATE RULE r1 AS ON INSERT RETURNING TO myview DO
--On Donnerstag, Februar 16, 2006 10:39:45 -0800 Dann Corbit
<[EMAIL PROTECTED]> wrote:
He refers to counting sort and radix sort (which comes in most
significant digit and least significant digit format). These are also
called distribution (as opposed to comparison) sorts.
These sorts are O(
--On Dienstag, Februar 14, 2006 10:35:12 -0600 hector Corrada Bravo
<[EMAIL PROTECTED]> wrote:
Before I start trying this (creating aggregate paths seems the
reasonable thing to do) I would like your counsel.
1) Regardless of the optimization problem, is the executor able to
execute aggregate
14 matches
Mail list logo
