>
> It doesn't do particularly well on my previous example of [1,2,3]. It
> comes out slightly shorter on ["a","b","c"] and better if the strings
> need any escaping. I don't think the float4 and float8 formats are
> very useful; how could you be sure that the output was going to look
> the same
On Sun, Oct 24, 2010 at 12:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose you could fix this by always updating every row, and storing
>> in each row the total count of elements (or a random number). Then
>> it'd be obvious if you'd read an inconsistent view of the world.
>
> Well, th
On Sat, Oct 23, 2010 at 8:33 PM, Terry Laurenzo wrote:
>>
>> I'm still going to write up a proposed grammar that takes these items into
>> account - just ran out of time tonight.
>>
>
> The binary format I was thinking of is here:
>
> http://github.com/tlaurenzo/pgjson/blob/master/pgjson/shared/
Robert Haas writes:
> I suppose you could fix this by always updating every row, and storing
> in each row the total count of elements (or a random number). Then
> it'd be obvious if you'd read an inconsistent view of the world.
Well, the easy way to read a consistent view of the world is to loa
On 10/23/2010 08:54 PM, Tom Lane wrote:
Another thought here is that the split-in-half rule might be
unnecessarily dumb. It leaves equal amounts of code space on both sides
of the new value, even though the odds of subsequent insertions on both
sides are probably unequal. But I'm not sure if
On Sat, Oct 23, 2010 at 8:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> Why would you need to lock out type comparisons?
>
> Didn't you get the point? The hazard is to a concurrent process that is
> merely trying to load up its enum-values cache so that it can perform an
> enum comparison. I
Andrew Dunstan writes:
> Seriously, I think it might be OK. Could we provide some safe way of
> resetting the sortorder values? Or even a not-entirely-safe
> superuser-only function might be useful. Binary upgrade could probably
> call it safely, for example.
You could do it with plain SQL, as
On 10/23/2010 07:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
Latest patch attached.
I've been working through this patch.
Cool.
[snip: reallocating enum sortorder on existing values has race
conditions. Suggestion to use a float8 instead and add new value half
way between neighbours,
>
>
> I'm still going to write up a proposed grammar that takes these items into
> account - just ran out of time tonight.
>
>
The binary format I was thinking of is here:
http://github.com/tlaurenzo/pgjson/blob/master/pgjson/shared/include/json/jsonbinary.h
This was just a quick brain dump and I
Robert Haas writes:
> Why would you need to lock out type comparisons?
Didn't you get the point? The hazard is to a concurrent process that is
merely trying to load up its enum-values cache so that it can perform an
enum comparison. I don't want such an operation to have to block,
especially no
On Oct 23, 2010, at 7:52 PM, Tom Lane wrote:
> I still prefer the idea of not changing rows once they're
> inserted, though
Me too. But I really dislike the idea of having a failure mode where we can't
insert for no reason that the user can understand. So I'm trying to think of a
better optio
Robert Haas writes:
> On Oct 23, 2010, at 7:12 PM, Tom Lane wrote:
>> I've been working through this patch. It occurs to me that there's a
>> fairly serious problem with the current implementation of insertion of
>> new values within the bounds of the current sort ordering. Namely, that
>> it d
On Oct 23, 2010, at 7:12 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Latest patch attached.
>
> I've been working through this patch. It occurs to me that there's a
> fairly serious problem with the current implementation of insertion of
> new values within the bounds of the current sort or
"A.M." writes:
> It seems that this:
> CREATE OR REPLACE FUNCTION test_fsync_speed() RETURNS float AS
> '$libdir/test_fsync_speed','\
> test_fsync_speed' LANGUAGE C IMMUTABLE STRICT;
> is not equivalent to this (note "void" argument):
> CREATE OR REPLACE FUNCTION test_fsync_speed(void) RETURNS
Josh Berkus writes:
>> The disadvantage of this scheme is that if you repeatedly insert entries
>> in the "same place" in the sort order, you halve the available range
>> each time, so you'd run out of room after order-of-fifty halvings.
> This is not a real issue. If anyone is using an ENUM wit
The disadvantage of this scheme is that if you repeatedly insert entries
in the "same place" in the sort order, you halve the available range
each time, so you'd run out of room after order-of-fifty halvings.
This is not a real issue. If anyone is using an ENUM with 1000 values
in it, they'r
Andrew Dunstan writes:
> Latest patch attached.
I've been working through this patch. It occurs to me that there's a
fairly serious problem with the current implementation of insertion of
new values within the bounds of the current sort ordering. Namely, that
it does that by reassigning the enu
So the trick for MERGE on equality would be to refactor the btree api
so that you could find the matching leaf page and *keep* that page
locked. Then do an update against the conflicting row found there if
any without ever releasing that page lock. Someone else can come along
and delete the row
On Sat, Oct 23, 2010 at 9:12 AM, Tom Lane wrote:
>> "PostgreSQL doesn't have a good way to lock access to a key value that
>> doesn't exist yet--what other databases call key range
>> locking...Improvements to the index implementation are needed to allow
>> this feature."
>
> This seems to be pres
On 21/10/10 20:48, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of jue oct 21 15:32:53 -0300 2010:
>> Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300
>> 2010:
>>
>>> I get this error when calling the function:
>>>
>>> test=# select foobar();
>>> ERROR:
>
>
> This did seem to find a bug in the implementation after running for a
> while:
>
> TRAP: FailedAssertion("!(epqstate->origslot != ((void *)0))", File:
> "execMain.c", Line: 1732)
>
> Line number there is relative to what you can see at
> http://github.com/greg2ndQuadrant/postgres/blob/merge/s
On Fri, Oct 22, 2010 at 12:08:54PM -0700, fazool mein wrote:
> Hello guys,
>
> I'm writing a function that will read data from the buffer in xlog
> (i.e. from XLogCtl->pages and XLogCtl->xlblocks). I want to make
> sure that I am doing it correctly.
Got an example of what the function might loo
Hello,
It seems that this:
CREATE OR REPLACE FUNCTION test_fsync_speed() RETURNS float AS
'$libdir/test_fsync_speed','\
test_fsync_speed' LANGUAGE C IMMUTABLE STRICT;
is not equivalent to this (note "void" argument):
CREATE OR REPLACE FUNCTION test_fsync_speed(void) RETURNS float AS
'$libdir/t
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a "null word",
with empty indexable rows entered in the index as if they contained the
null word. So there'd be just one index en
On 2010-10-23 18:42, Tom Lane wrote:
Jesper Krogh writes:
I have been puzzled about the evaluation order when using window
functions and limit.
It's basically FROM -> WHERE -> window functions -> LIMIT.
I expected it to either count to 3 or blow up and tell me that count(*)
w
Jesper Krogh writes:
> I have been puzzled about the evaluation order when using window
> functions and limit.
It's basically FROM -> WHERE -> window functions -> LIMIT.
> I expected it to either count to 3 or blow up and tell me that count(*)
> wasn't a window function.
Any aggregate function
Hi.
I have been puzzled about the evaluation order when using window
functions and limit.
jk=# select * from testtable;
id | value
+---
1 | 1
2 | 2
3 | 3
4 | 4
5 | 5
6 | 6
7 | 7
8 | 8
9 | 9
10 |10
(10 rows)
jk=# select id,count
Greg Smith writes:
> Marko Tiikkaja wrote:
>> What's been bothering me is that so far there has not been an
>> agreement on whether we need to protect against concurrency issues or
>> not. In fact, there has been almost no discussion about the
>> concurrency issues which AIUI have been the big
Marko Tiikkaja wrote:
What's been bothering me is that so far there has not been an
agreement on whether we need to protect against concurrency issues or
not. In fact, there has been almost no discussion about the
concurrency issues which AIUI have been the biggest single reason we
don't have
Tom Lane wrote:
> Bruce Momjian writes:
> > Greg Stark wrote:
> >> It seems to me simpler and more direct to just nail relcache
> >> entries for these objects into memory and manipulate them directly.
> >> They can be constructed from the global catalog tables and then
> >> tweaked to point to the
On 2010-10-23 8:34 AM +0300, Greg Smith wrote:
While the performance doesn't need to be great in V1, there needs to be
at least some minimal protection against concurrency issues before this
is commit quality.
What's been bothering me is that so far there has not been an agreement
on whether w
On tor, 2010-10-21 at 06:38 +0300, Peter Eisentraut wrote:
> So, as previously indicated, let's add some wildcard support to the
> pg_hba.conf host name feature. After looking around a bit, two syntaxes
> appear to be on offer:
>
> 1. TCP Wrappers style, leading dot indicates suffix match.
> So .
> Before you start coding, have you looked over what's in
> contrib/intarray ?
There's nothing that fulfills my needs there, but I guess it
would be the perfect place to watch for code examples!
Thank you
(I think I made my custom aggregation function work,
but I'll look into intarray code to
33 matches
Mail list logo
