-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 treatment
-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-patch:
-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 suggestion
-- backup-server with fast disks
;
and then something like
synchronize_mode = immediate_readonly;
Yeah, I know, give patches not pipe-dreams :)
Regards,
Jens-Wolfhard Schicke
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIhoAdzhchXT4RR5ARAo/6AJ9R6LA0TsPvD
-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
not help.
Regards,
Jens-Wolfhard Schicke
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHUwM7zhchXT4RR5ARAsziAJ9qm/c8NuaJ+HqoJo9Ritb2t92fRwCgnF9J
r5YU/Fa0mNYG7YXed4QW7K4=
=Mvyj
-END PGP SIGNATURE-
---(end of broadcast
-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
--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
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
--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
--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
--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
