Simon Riggs <[EMAIL PROTECTED]> writes:
> Right now it seems strange that the index is larger than a btree, yet
> the performance tests show that 3 times as much I/O was used accessing
> the btree.
Well, in an ideal world a hash index probe is O(1) while a btree probe
is O(log N), so that result i
On Wed, Sep 3, 2008 at 10:06 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> It seems hash index is a little better on index creation and
>> selection.
>> But maybe it's in the range of noise, I'm not sure.
>> I'd like to try it with a bigger dataset (e.g. table with 10GB) but
>> there is not enough
On Mon, 2008-08-18 at 09:46 +0800, Xiao Meng wrote:
> There's minor change against the previous
> one( http://archives.postgresql.org/pgsql-hackers/2008-07/msg01183.php ).
> * merge branch master(Aug 16) into the patch
> * clean code and make some comment
> Performance result is here
> http://wik
I thought -patches was supposed to die. What happened?
-- ams
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Andrew Chernow wrote:
This is an updated version pf the libpqevents patch. See
http://archives.postgresql.org/pgsql-hackers/2008-09/msg00153.php
for details. The only change I didn't make yet is the event 'name'. I
have put it in and taken it out twice now, so a firm 'put it in there'
woul
Andrew Chernow wrote:
> This is an updated version pf the libpqevents patch. See
>
> http://archives.postgresql.org/pgsql-hackers/2008-09/msg00153.php
>
> for details. The only change I didn't make yet is the event 'name'. I
> have put it in and taken it out twice now, so a firm 'put it in the
This is an updated version pf the libpqevents patch. See
http://archives.postgresql.org/pgsql-hackers/2008-09/msg00153.php
for details. The only change I didn't make yet is the event 'name'. I
have put it in and taken it out twice now, so a firm 'put it in there'
would be appreciated.
Go
Hi folks,
As discussed on -hackers [1], here is a patch to add a pg_typeof()
builtin function to core.
The function accepts one argument (type "any") and returns the regtype
of that argument. This can be helpful in various circumstances,
including troubleshooting cast/coercion behaviour in a que
