On Wed, Sep 21, 2011 at 7:51 AM, Heikki Linnakangas
wrote:
> On 21.09.2011 02:53, Peter Geoghegan wrote:
>>
>> C stdlib quick-sort time elapsed: 2.092451 seconds
>> Inline quick-sort time elapsed: 1.587651 seconds
>>
>> Does *that* look attractive to you?
>
> Not really, to be honest. That's a 25%
On 21.09.2011 10:01, Simon Riggs wrote:
On Wed, Sep 21, 2011 at 7:51 AM, Heikki Linnakangas
wrote:
On 21.09.2011 02:53, Peter Geoghegan wrote:
C stdlib quick-sort time elapsed: 2.092451 seconds
Inline quick-sort time elapsed: 1.587651 seconds
Does *that* look attractive to you?
Not really
2011/9/21 Shigeru Hanada
> Hi Michael,
>
> (2011/09/21 12:52), Michael Paquier wrote:
> > I am interested in the development you are doing regarding join push down
> > and fdw stuff for remote postgreSQL servers.
> > Is there a way to get the postgres fdw you are providing here for common
> > 9.1
On Mon, 2011-09-19 at 18:32 +0200, Florian Pflug wrote:
> No, but more similar the format are the easier it gets to at least factor
> the hairy parts of such a parser into a common subroutine. Assume that we
> don't support NULL as an alias for INF. What would then be the result of
>
> '[A,NULL)
On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote:
> What I really
> care about is that we don't talk ourselves into needing a zillion
> constructor functions. Making things work with a single constructor
> function seems to me to simplify life quite a bit, and allowing there
> seems essential
On 21 September 2011 01:48, wrote:
> All -O2 version show 42% speedup with inlined qsort.
> -O0 showed 25% speedup.
Thanks. Looks like the figures I posted last night were fairly
conservative. Does anyone else care to report results?
--
Peter Geoghegan http://www.2ndQuadrant.com/
Postgre
Hello all,
I'm writing a C-language function that is similar to nextval() but
should return the next member of the recurrent sequence:
T(n+1) = f(T(n), T(n-1), ..., T(n-k)), where f is some function and k is
a constant.
The state of this object should be persistent between database restarts
an
On Wed, Sep 21, 2011 at 08:23, Fujii Masao wrote:
> On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander wrote:
>> On Wed, Sep 21, 2011 at 04:50, Fujii Masao wrote:
>>> 3. Copy the pg_control file from the cluster directory on the standby to
>>> the backup as follows:
>>>
>>> cp $PGDATA/global
2011/9/19 Matthew Wilcox :
> On Mon, Sep 19, 2011 at 08:31:00AM -0400, Stephen Frost wrote:
>> * Benjamin LaHaise (b...@kvack.org) wrote:
>> > For such tables, can't Postgres track the size of the file internally? I'm
>> > assuming it's keeping file descriptors open on the tables it manages, in
>>
This attempts to be as simple as it gets while reducing function call
depth, and should be viewed as a proof of concept. It is also untested
as of now, but will try to do that and report back.
I'm hoping I followed the rabbit hole correctly and are correctly
comparing the right pointers to each ot
>Recent discussions on the threads "Double sorting split patch" and
>"CUDA sorting" raised the possibility that there could be significant
>performance optimisation "low-hanging fruit" picked by having the
>executor treat integers and floats as a special case during sorting,
>avoiding going to
On Sep21, 2011, at 09:23 , Jeff Davis wrote:
> On Mon, 2011-09-19 at 18:32 +0200, Florian Pflug wrote:
>> No, but more similar the format are the easier it gets to at least factor
>> the hairy parts of such a parser into a common subroutine. Assume that we
>> don't support NULL as an alias for INF.
On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis wrote:
> On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote:
>> What I really
>> care about is that we don't talk ourselves into needing a zillion
>> constructor functions. Making things work with a single constructor
>> function seems to me to simpli
On Wed, Sep 21, 2011 at 8:19 AM, Vlad Arkhipov wrote:
> I'm writing a C-language function that is similar to nextval() but should
> return the next member of the recurrent sequence:
> T(n+1) = f(T(n), T(n-1), ..., T(n-k)), where f is some function and k is a
> constant.
> The state of this object
On Sep21, 2011, at 14:00 , Robert Haas wrote:
> On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis wrote:
>> On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote:
>>> (I am also vaguely wondering what happens if if you have a text
>>> range is (nubile, null) ambiguous?)
>>
>> There are a few ways to
On Wed, Sep 21, 2011 at 8:41 AM, Florian Pflug wrote:
>> Boy, that seems really weird to me. If you're going to do it, it
>> ought to be case-insensitive, but I think detecting the case only for
>> the purpose of rejecting it is probably a mistake. I mean, if
>> (nubile, nutty) is OK, then (nubi
On Wed, Sep 21, 2011 at 8:08 AM, Heikki Linnakangas
wrote:
>> How about almost every primary index creation?
>
> Nope. Swamped by everything else.
Really? I think it's pretty common for shops to be able to dedicate
large amounts of RAM to building initial indexes on data loads or
reindex operatio
On Wed, Sep 21, 2011 at 8:47 AM, Greg Stark wrote:
> On Wed, Sep 21, 2011 at 8:08 AM, Heikki Linnakangas
> wrote:
>>> How about almost every primary index creation?
>>
>> Nope. Swamped by everything else.
>
> Really? I think it's pretty common for shops to be able to dedicate
> large amounts of R
On 21 September 2011 07:51, Heikki Linnakangas
wrote:
> On 21.09.2011 02:53, Peter Geoghegan wrote:
>>
>> C stdlib quick-sort time elapsed: 2.092451 seconds
>> Inline quick-sort time elapsed: 1.587651 seconds
>>
>> Does *that* look attractive to you?
>
> Not really, to be honest. That's a 25% spee
On 21.09.2011 17:20, Peter Geoghegan wrote:
Even still, I
think that the 12.5% figure is pretty pessimistic - I've already sped
up the dell store query by almost that much, and that's with a patch
that was, due to circumstances, cobbled together.
I'm not against making things faster, it's just
Florian Pflug writes:
> On Sep21, 2011, at 14:00 , Robert Haas wrote:
>> Otherwise, anyone
>> who wants to construct these strings programatically is going to need
>> to escape everything and always write ("cat","dog") or however you do
>> that, and that seems like an unnecessary imposition.
> Un
Heikki Linnakangas writes:
> On 21.09.2011 17:20, Peter Geoghegan wrote:
>> Even still, I
>> think that the 12.5% figure is pretty pessimistic - I've already sped
>> up the dell store query by almost that much, and that's with a patch
>> that was, due to circumstances, cobbled together.
> I'm not
Hello,
* Context *
I'm observing problems with provisioning a standby from the master by
following a basic and documented "Making a Base Backup" [1] procedure with
rsync if, in the mean time, heavy load is applied on the master.
After searching the archives, the only more discussed and similar i
On 09/21/2011 10:50 AM, Tom Lane wrote:
The other question that I'm going to be asking is whether it's not
possible to get most of the same improvement with a much smaller code
footprint. I continue to suspect that getting rid of the SQL function
impedance-match layer (myFunctionCall2Coll etc)
Hi,
I find the current behaviour of locking of sequences rather problematic.
Multiple things:
- First and foremost I find it highly dangerous that "ALTER SEQUENCE ..." is
for the biggest part not transactional. I think about the only transaction
part is the name, owner and schema.
Sure, its do
On Sep21, 2011, at 16:41 , Tom Lane wrote:
> Florian Pflug writes:
>> On Sep21, 2011, at 14:00 , Robert Haas wrote:
>>> Otherwise, anyone
>>> who wants to construct these strings programatically is going to need
>>> to escape everything and always write ("cat","dog") or however you do
>>> that, an
Simon Riggs writes:
> This is a marvellous win, a huge gain from a small, isolated and
> easily tested change. By far the smallest amount of additional code to
> sorting we will have added and yet one of the best gains.
I think you forgot your cheerleader uniform. A patch along these lines
is no
Hello Alvaro,
On 16.09.2011 15:08, Alvaro Herrera wrote:
It's certainly possible to create a private mailing list to support this
idea. How would the membership be approved, however, is not clear to
me. Would we let only well-known names from other pgsql lists into it?
(I, for one, had no ide
On 21 September 2011 15:50, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I'm not against making things faster, it's just that I haven't seen
>> solid evidence yet that this will help. Just provide a best-case test
>> case for this that shows a huge improvement, and I'll shut up. If the
>> impr
Andrew Dunstan writes:
> On 09/21/2011 10:50 AM, Tom Lane wrote:
>> The other question that I'm going to be asking is whether it's not
>> possible to get most of the same improvement with a much smaller code
>> footprint. I continue to suspect that getting rid of the SQL function
>> impedance-mat
On 21.09.2011 18:46, Tom Lane wrote:
Andrew Dunstan writes:
On 09/21/2011 10:50 AM, Tom Lane wrote:
The other question that I'm going to be asking is whether it's not
possible to get most of the same improvement with a much smaller code
footprint. I continue to suspect that getting rid of the
On Wed, Sep 21, 2011 at 4:46 PM, Tom Lane wrote:
> As such, they could not have entries in pg_proc, so
> it seems like there's no ready way to represent them in the catalogs.
Why couldn't they be in pg_proc with a bunch of opaque arguments like
the GIST opclass support functions?
I'm a bit puzz
Heikki Linnakangas writes:
> On 21.09.2011 18:46, Tom Lane wrote:
>> The idea that I was toying with was to allow the regular SQL-callable
>> comparison function to somehow return a function pointer to the
>> alternate comparison function,
> You could have a new function with a pg_proc entry, tha
On 21.09.2011 18:46, Tom Lane wrote:
Well, we'd have to negotiate what the API ought to be. What I'm
envisioning is that datatypes could provide alternate comparison
functions that are designed to be qsort-callable rather than
SQL-callable. As such, they could not have entries in pg_proc, so
it
Hi all,
Whats the reason for disallowing cursors on wCTEs? I am not sure I can follow
the comment:
/*
* We also disallow data-modifying WITH in a cursor. (This could be
* allowed, but the semantics of when the updates occur might be
* surprising.)
*/
Greg Stark writes:
> On Wed, Sep 21, 2011 at 4:46 PM, Tom Lane wrote:
>> As such, they could not have entries in pg_proc, so
>> it seems like there's no ready way to represent them in the catalogs.
> Why couldn't they be in pg_proc with a bunch of opaque arguments like
> the GIST opclass suppor
On 21-09-2011 11:44, Linas Virbalas wrote:
[This question doesn't belong to -hackers. Please post it in -general or -admin]
Procedure:
1. Start load generator on the master (WAL archiving enabled).
2. Prepare a Streaming Replication standby (accepting WAL files too):
2.1. pg_switch_xlog() on t
Heikki Linnakangas writes:
> On 21.09.2011 18:46, Tom Lane wrote:
>> Well, we'd have to negotiate what the API ought to be. What I'm
>> envisioning is that datatypes could provide alternate comparison
>> functions that are designed to be qsort-callable rather than
>> SQL-callable. As such, they
Hi guys!
I know Postgresql 9.x includes "unaccent" contrib on their deliver package.
"unaccent" is compatible with postgresql 8.4 (but not is in their contrib
version distribution)
what's better way to setup "unaccent" module on Postgresql 8.4 production
server.
Copy contrib/unaccent from 9.x t
On Sep21, 2011, at 16:44 , Linas Virbalas wrote:
> After searching the archives, the only more discussed and similar issue I
> found hit was by Daniel Farina in a thread "hot backups: am I doing it
> wrong, or do we have a problem with pg_clog?" [2], but, it seems, the issue
> was discarded because
On Wed, Sep 21, 2011 at 5:23 PM, Tom Lane wrote:
> None of that stuff is inlinable or constant-foldable today, nor would it
> be with the patch that Peter was proposing AFAICS, because none of the
> flags will ever be compile time constant values.
I was referring to transformations like this whic
Excerpts from Peter Eisentraut's message of mié sep 21 00:27:53 -0300 2011:
>
> On tis, 2011-09-20 at 11:12 -0300, Alvaro Herrera wrote:
> > > > +1 for a closed mailing list. It's a bit annoying to have to do
> > > > such a thing, but it's not like we haven't got other closed
> > > > lists for a
On Wed, Sep 21, 2011 at 5:49 PM, Alvaro Herrera
wrote:
>
> Excerpts from Peter Eisentraut's message of mié sep 21 00:27:53 -0300 2011:
>>
>> On tis, 2011-09-20 at 11:12 -0300, Alvaro Herrera wrote:
>> > > > +1 for a closed mailing list. It's a bit annoying to have to do
>> > > > such a thing, but
Andres Freund wrote:
> - Its impossible to emulate proper locking yourself because
> locking is not allowed for sequences
> Any arguments against allowing it again? It seems to have been
> allowed in prehistoric times.
It would be nice to allow it. I've had to create a dummy table just
to u
Fujii,
I haven't really been following your latest patches about taking backups
from the standby and cascading replication, but I wanted to see if it
fulfills another TODO: the ability to "remaster" (that is, designate the
"lead standby" as the new master) without needing to copy WAL files.
Suppo
On Wed, Sep 21, 2011 at 11:51 AM, Kevin Grittner
wrote:
> Andres Freund wrote:
>
>> - Its impossible to emulate proper locking yourself because
>> locking is not allowed for sequences
>
>> Any arguments against allowing it again? It seems to have been
>> allowed in prehistoric times.
>
> It would
Robert,
> Josh is arguing that we ought to use the term "replication", but it
Actually, no. I'm arguing that we should use the term "standby", since
that term is consistent with how we refer to replica servers throughout
the docs, and the term "recovery" is not.
> seems to me that's just as misl
On Wed, Sep 21, 2011 at 12:55 PM, Josh Berkus wrote:
>> Josh is arguing that we ought to use the term "replication", but it
>
> Actually, no. I'm arguing that we should use the term "standby", since
> that term is consistent with how we refer to replica servers throughout
> the docs, and the term
On Wed, 2011-09-21 at 17:20 +0200, Florian Pflug wrote:
> Hm, so we'd have
>
> '(X,)' for range(X, NULL, '()'),
> '(,X)' for range(NULL, X, '()') and
> '(,)' for range(NULL, NULL, '()').
>
> We'd then have the choice of either declaring
>
> '(X,]' to mean '(X,)',
> '[,X)' to mean '(,X)
On Wed, 2011-09-21 at 13:24 +0200, Florian Pflug wrote:
> I've thought about this some more, and came to realize that the question
> here really is whether
>
> floatrange(0, 'Infinity'::float, '[)')
>
> and
>
> floatrange(0, NULL, '[)')
>
> are the same thing or not.
The unbounded side of
Merlin Moncure wrote:
> On Wed, Sep 21, 2011 at 11:51 AM, Kevin Grittner
> wrote:
>> Andres Freund wrote:
>>
>>> - Its impossible to emulate proper locking yourself because
>>> locking is not allowed for sequences
>>
>>> Any arguments against allowing it again? It seems to have been
>>> allowed
> Yeah, I get it. But I think standby would confuse them, too, just in
> a different set of situations.
Other than PITR, what situations?
PITR is used by a minority of our users. Binary replication, if not
already used by a majority, will be in the future (it's certainly the
majority of my pro
On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
>> Yeah, I get it. But I think standby would confuse them, too, just in
>> a different set of situations.
>
> Other than PITR, what situations?
Hot backup?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
On 9/21/11 10:07 AM, Robert Haas wrote:
> On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
>>> Yeah, I get it. But I think standby would confuse them, too, just in
>>> a different set of situations.
>>
>> Other than PITR, what situations?
>
> Hot backup?
Hot backup == PITR. You're just not
=?ISO-8859-1?Q?Gunnlaugur_=DE=F3r_Briem?= writes:
> On Monday, September 19, 2011 3:59:30 AM UTC, Tom Lane wrote:
>> Works for me in 8.4.8. Do you have constraint_exclusion set to ON?
> I did try with constraint_exclusion set to on, though the docs suggest
> partition should be enough ("examine
On Wed, Sep 21, 2011 at 1:08 PM, Josh Berkus wrote:
> On 9/21/11 10:07 AM, Robert Haas wrote:
>> On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
Yeah, I get it. But I think standby would confuse them, too, just in
a different set of situations.
>>>
>>> Other than PITR, what situati
On Wednesday 21 Sep 2011 19:03:17 Kevin Grittner wrote:
> Merlin Moncure wrote:
> > On Wed, Sep 21, 2011 at 11:51 AM, Kevin Grittner
> >
> > wrote:
> >> Andres Freund wrote:
> >>> - Its impossible to emulate proper locking yourself because
> >>> locking is not allowed for sequences
> >>>
> >>>
On Wed, Sep 21, 2011 at 12:22 PM, Euler Taveira de Oliveira
wrote:
> [This question doesn't belong to -hackers. Please post it in -general or
> -admin]
-hackers or -bugs seems appropriate to me; I think this is a bug.
>> 2.2. pg_start_backup(Obackup_under_loadš) on the master (this will take a
>
"Kevin Grittner" writes:
> Andres Freund wrote:
>> - Its impossible to emulate proper locking yourself because
>> locking is not allowed for sequences
>> Any arguments against allowing it again? It seems to have been
>> allowed in prehistoric times.
If you think that it used to be allowed, it'
On Wed, Sep 21, 2011 at 1:13 PM, Robert Haas wrote:
> On Wed, Sep 21, 2011 at 1:08 PM, Josh Berkus wrote:
>> On 9/21/11 10:07 AM, Robert Haas wrote:
>>> On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
> Yeah, I get it. But I think standby would confuse them, too, just in
> a differe
On Wed, Sep 21, 2011 at 1:34 PM, Aidan Van Dyk wrote:
> And I think Tom touched on this point in the
> "recovery.conf/recovery.done" thread a bit too.
Doh! That's this thread
/me slinks away, ashamed for not even taking a close look at the to/cc list...
--
Aidan Van Dyk
On Wednesday 21 Sep 2011 19:24:55 Tom Lane wrote:
> "Kevin Grittner" writes:
> > Andres Freund wrote:
> >> - Its impossible to emulate proper locking yourself because
> >> locking is not allowed for sequences
> >>
> >> Any arguments against allowing it again? It seems to have been
> >> allowed i
On 21-09-2011 13:28, Daniel Vázquez wrote:
"unaccent" is compatible with postgresql 8.4 (but not is in their contrib
version distribution)
No, it is not. AFAICS it is necessary to add some backend code that is not in
8.4.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com
Hi,
I notice that HeapTupleSatisfiesToast is not setting the
HEAP_XMIN_COMMITTED bit, though it is reading it. Is there a reason for
this? It seems to me that it'd make sense to have it set ... unless
it's set by some other routine, somehow?
--
Álvaro Herrera
--
Sent via pgsql-hackers mail
Andres Freund wrote:
> On Wednesday 21 Sep 2011 19:24:55 Tom Lane wrote:
>> One question is what you think the lock means. I believe for
>> example that taking a non-exclusive regular table lock on a
>> sequence would not prevent other sessions from doing nextval();
>> even an exclusive one wou
On Wed, Sep 21, 2011 at 12:03 PM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>> On Wed, Sep 21, 2011 at 11:51 AM, Kevin Grittner
>> wrote:
>>> Andres Freund wrote:
>>>
- Its impossible to emulate proper locking yourself because
locking is not allowed for sequences
>>>
Any argu
... ok
No alternatives for unaccent on 8.4?
2011/9/21 Euler Taveira de Oliveira
> On 21-09-2011 13:28, Daniel Vázquez wrote:
>
>> "unaccent" is compatible with postgresql 8.4 (but not is in their contrib
>> version distribution)
>>
>> No, it is not. AFAICS it is necessary to add some backend co
On Thu, Sep 15, 2011 at 11:57 AM, Heikki Linnakangas
wrote:
> s/atomic/barrier/
Oops.
>> +/*
>> + * A compiler barrier need not (and preferably should not) emit any
>> actual
>> + * machine code, but must act as an optimization fence: the compiler must
>> not
>> + * reorder loads or stores to ma
Robert Haas wrote:
> But even a full explanation of that case seems like almost too
> much for the comment of a header file, and there are certainly far
> more complex cases. I think anyone who is using these primitives
> is going to have to do some independent reading...
Maybe a URL or two i
On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera wrote:
>
> Hi,
>
> I notice that HeapTupleSatisfiesToast is not setting the
> HEAP_XMIN_COMMITTED bit, though it is reading it. Is there a reason for
> this? It seems to me that it'd make sense to have it set ... unless
> it's set by some other rou
On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> But even a full explanation of that case seems like almost too
>> much for the comment of a header file, and there are certainly far
>> more complex cases. I think anyone who is using these primitives
>> is going to h
Excerpts from Merlin Moncure's message of mié sep 21 16:02:34 -0300 2011:
> On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera
> wrote:
> >
> > Hi,
> >
> > I notice that HeapTupleSatisfiesToast is not setting the
> > HEAP_XMIN_COMMITTED bit, though it is reading it. Is there a reason for
> > this?
On Wed, Sep 21, 2011 at 4:22 PM, Tom Lane wrote:
> Simon Riggs writes:
>> This is a marvellous win, a huge gain from a small, isolated and
>> easily tested change. By far the smallest amount of additional code to
>> sorting we will have added and yet one of the best gains.
>
> I think you forgot
On Wed, Sep 21, 2011 at 2:14 PM, Alvaro Herrera
wrote:
>
> Excerpts from Merlin Moncure's message of mié sep 21 16:02:34 -0300 2011:
>> On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera
>> wrote:
>> >
>> > Hi,
>> >
>> > I notice that HeapTupleSatisfiesToast is not setting the
>> > HEAP_XMIN_COMMIT
On 05.09.2011 09:39, Oleg Bartunov wrote:
I attached wrong patch in previous message, sorry ! Here is a last version.
One little detail caught my eye: In spgSplitNodeAction, you call
SpGistGetBuffer() within a critical section. That should be avoided,
SpGistGetBuffer() can easily fail if you
Robert Haas wrote:
> On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>> But even a full explanation of that case seems like almost too
>>> much for the comment of a header file, and there are certainly
>>> far more complex cases. I think anyone who is using these
On 21-09-2011 15:23, Daniel Vázquez wrote:
No alternatives for unaccent on 8.4?
Not that I know of.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql
Alvaro Herrera writes:
> I notice that HeapTupleSatisfiesToast is not setting the
> HEAP_XMIN_COMMITTED bit, though it is reading it. Is there a reason for
> this? It seems to me that it'd make sense to have it set ... unless
> it's set by some other routine, somehow?
Hmm ... I wonder if that h
Alvaro Herrera writes:
> More interesting, however, is the fact that the XMAX_COMMITTED bit is
> never set either. I guess the rows are deleted by a different mechanism
> (tuptoaster probably) -- it isn't obvious how this works just by looking
> at tqual.c. It seems to do nothing at all.
I have
On Wed, Sep 14, 2011 at 4:29 PM, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
> > I've been thinking about this too and actually went so far as to do
> > some research and put together something that I hope covers most of
> > the interesting cases. The attached patch
On Wed, Sep 21, 2011 at 4:19 PM, Gurjeet Singh wrote:
> On Wed, Sep 14, 2011 at 4:29 PM, Robert Haas wrote:
>>
>> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
>> > I've been thinking about this too and actually went so far as to do
>> > some research and put together something that I hope
On Wed, 2011-09-21 at 18:28 +0200, Daniel Vázquez wrote:
> Can Global Development Group, make some acumulative rpm for contrib
> modules that are backward compatible???
No (as the RPM maintainer).
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL
Euler Taveira de Oliveira writes:
> On 21-09-2011 13:28, Daniel Vázquez wrote:
>> "unaccent" is compatible with postgresql 8.4 (but not is in their contrib
>> version distribution)
> No, it is not. AFAICS it is necessary to add some backend code that is not in
> 8.4.
[ pokes at it ] Yeah, you
On Wed, Sep 21, 2011 at 3:39 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
>> wrote:
>>> Robert Haas wrote:
But even a full explanation of that case seems like almost too
much for the comment of a header file, and there are certainly
Robert Haas wrote:
> there are three questions that you might want to answer here:
>
> 1. I have a new architecture and I want barrier.h to support it.
>What do I need to do?
> 2. What is the behavior of the various constructs provided by
>barrier.h?
> 3. Why would I want that behavior
Robert Haas writes:
> On Tue, Sep 20, 2011 at 8:19 PM, Tom Lane wrote:
>> I find it useless and probably confusing to put out "Rows Removed
>> by Recheck Cond: 0" unless we're dealing with a lossy index.
> I don't really see the point of this. I think printing it always is
> both clear and appr
I've processed the results of the tests with double sorting split which I've
sheduled for buffering build. I've updated wiki page with them:
http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011#Testing_results
Raw results of query speed measues are in the attachment. There number of
page
All,
I just tripped over this:
select 'josh'::varchar(32) = 'Josh'::citext;
?column?
--
f
While it's clear why it's that way, it's not how people would expect
citext to behave. Users expect case-insensitive text to be
case-insensitive for *all* comparisons, not just for comparisons wi
Josh Berkus writes:
> I'd like to patch the citext contrib module for 9.2 to fix this by
> creating four new = operators to establish the comparison function for
> text and varchar.
I think you'll find that's easier said than done (problem 1 is going to
be ambiguity, and problem 2 is going to be
> I think you'll find that's easier said than done (problem 1 is going to
> be ambiguity,
Ambiguity?
> and problem 2 is going to be that comparisons involving
> these operators won't get indexed).
Yeah, that's acceptable, since it's not any worse than the behavior of
the comparisons now.
--
On Sep21, 2011, at 19:00 , Jeff Davis wrote:
> While we're at it, any suggestions on the text representation of an
> empty range?
My personal favourite would be '0', since it resembles the symbol used
for empty sets in mathematics, and we already decided to use mathematical
notation for ranges.
I
On Tue, Sep 13, 2011 at 10:13 PM, Kyotaro HORIGUCHI
wrote:
> This is rebased patch of `Allow encoding specific character
> incrementer'(https://commitfest.postgresql.org/action/patch_view?id=602).
>
> Addition to the patch, increment sanity check program for new
> functions pg_generic_charinc and
On Sep21, 2011, at 19:02 , Jeff Davis wrote:
> On Wed, 2011-09-21 at 13:24 +0200, Florian Pflug wrote:
>> I've thought about this some more, and came to realize that the question
>> here really is whether
>>
>> floatrange(0, 'Infinity'::float, '[)')
>>
>> and
>>
>> floatrange(0, NULL, '[)')
>>
Josh Berkus writes:
>> I think you'll find that's easier said than done (problem 1 is going to
>> be ambiguity,
> Ambiguity?
Yeah, I'm worried about the possibility of parser failing to resolve
which operator is meant.
>> and problem 2 is going to be that comparisons involving
>> these operato
>> Ambiguity?
>
> Yeah, I'm worried about the possibility of parser failing to resolve
> which operator is meant.
Any idea of how to test for that? What kind of situations would make
things difficult for the parser?
Also, how is this any different for any optional data type which
overrides = ?
On 09/20/2011 09:35 AM, Heikki Linnakangas wrote:
Yeah, I was thinking of write()s, not fsyncs. I agree this might have
some effect during fsync phase.
Right; that's where the most serious problems seem to pop up at anyway
now. All the testing I did earlier this year suggested Linux at least
Josh Berkus writes:
>> Yeah, I'm worried about the possibility of parser failing to resolve
>> which operator is meant.
> Any idea of how to test for that? What kind of situations would make
> things difficult for the parser?
Not sure, but it would be underspecified cases such as 'x' = 'x' that
Robert Haas writes:
> As I understand it, the issue here is that when we try to generate
> suitable > and < quals for a LIKE expression, we need to find a string
> which is greater than the prefix we're searching for, and the existing
> algorithm sometimes fails. But there seems to be some disput
On Wed, Sep 21, 2011 at 9:49 PM, Tom Lane wrote:
> The main risk that I foresee with the proposed approach is that if you
> have, say, a 4-byte final character, you could iterate through a *whole
> lot* (millions) of larger encoded characters, with absolutely no hope of
> making a greater string t
On Sep 21, 2011, at 6:12 PM, Tom Lane wrote:
>> Any idea of how to test for that? What kind of situations would make
>> things difficult for the parser?
>
> Not sure, but it would be underspecified cases such as 'x' = 'x' that
> might have trouble. I may be worrying over nothing --- I'm just tr
1 - 100 of 105 matches
Mail list logo
