Andrew Dunstan wrote:
> > Are you suggesting we just delete the threads and let them die if they
> > don't submit a new version?
> >
> >
>
> My understanding was that all items in a commit-fest have one of these
> three dispositions:
>
> . committed
> . rejected
> . referred back to author fo
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > My understanding was that all items in a commit-fest have one of these
> > three dispositions:
>
> > . committed
> > . rejected
> > . referred back to author for more work
>
> Right. But Bruce's personal queue has got a different
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> My understanding was that all items in a commit-fest have one of these
> three dispositions:
> . committed
> . rejected
> . referred back to author for more work
Right. But Bruce's personal queue has got a different lifecycle:
items get removed when
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Er, why "saved"? Until there's a new patch submission there's not going
to be more work to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are you suggesting we just delete the threads and let them die if they
> don't submit a new version?
I am suggesting that they are not material for another commit fest until
some new work has been done. (And the appearance of that new work would
trigger
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This has been saved for the next commit-fest:
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Er, why "saved"? Until there's a new patch submission there's not going
> to be more work to do on this in the next fest.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This has been saved for the next commit-fest:
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Er, why "saved"? Until there's a new patch submission there's not going
to be more work to do on this in the next fest.
I think maybe you need to
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are downsides:
Insurmountable ones at that. This one already makes it a non-starter:
> a) the overhead of counting rows and loops is there for every query execution,
> even if you don't do explain analyze.
and you are also engaging in a flight
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >> Attached is
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I know I should still be looking at code from the March Commitfest but I was
>> annoyed by this *very* FAQ:
>
>> http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
>
> Seems like pg_relation_size
Gregory Stark <[EMAIL PROTECTED]> writes:
> I know I should still be looking at code from the March Commitfest but I was
> annoyed by this *very* FAQ:
> http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
Seems like pg_relation_size and/or pgstattuple would solve his problem
bette
Folks,
In psql, \dT doesn't show the elements for enums. Please find patch
vs. CVS TIP attached which fixes this per the following TODO item:
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php
Cheers,
David.
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 23
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>>> You could satisfy '%foo%' using a regular and a reverse B-tree index,
>>> and a bitmap AND. Which is interestingly similar to the way you
>>> proposed to use a TIDBitmap within GIN.
>>
>> Huh, can you? I can se
Not to be opened before May 1st!
I know I should still be looking at code from the March Commitfest but I was
annoyed by this *very* FAQ:
http://archives.postgresql.org/pgsql-general/2008-04/msg00402.php
This also came up at the UKUUG-Pg conference so it was already on my mind. I
couldn't r
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Teodor Sigaev wrote:
GIN speeds up '%foo%' too - which is impossible for btree. But I don't
like a hack around LIKE support in BTree. This support uses outflank
ways missing regular one.
You could satisfy '%foo%' using a regular and a reverse
Heikki Linnakangas wrote:
> Teodor Sigaev wrote:
>> GIN speeds up '%foo%' too - which is impossible for btree. But I don't
>> like a hack around LIKE support in BTree. This support uses outflank
>> ways missing regular one.
>
> You could satisfy '%foo%' using a regular and a reverse B-tree ind
Teodor Sigaev wrote:
Looking at the patch, you require that the TIDBitmap fits in work_mem
in non-lossy format. I don't think that's acceptable, it can easily
exceed work_mem if you search for some very common word. Failing to
execute a valid query is not good.
But way is better than nothing. I
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
> - compare function has third (optional) argument, of boolean type, it points
> to
>kind of compare: partial or exact match. If argument is equal to 'false',
>function should produce comparing as usual, else function's result is
>treated a
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> There's a bunch of mails in the patch queue about the indexam API, so we need
> to discuss that.
>
> The first question is: do we want to refactor the bitmap index scan API, if we
> don't have any immediate use for it? Namely, since we don't have
Looking at the patch, you require that the TIDBitmap fits in work_mem in
non-lossy format. I don't think that's acceptable, it can easily exceed
work_mem if you search for some very common word. Failing to execute a
valid query is not good.
But way is better than nothing. In really, that way was
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Attached patch implements wal_sync_method as an enum. I'd like
> > someone to look it over before I apply it - I don't have the
> > machines to test all codepaths (and some of it is hard to test -
> > better to read it and make sure it's right).
>
[what should happen if a smart shutdown request is received during online
backup mode?
I'll cc: the hackers list, maybe others have something to say to this]
Heikki Linnakangas wrote:
> Albe Laurenz wrote:
>> Moreover, if Shutdown == SmartShutdown, new connections won't be accepted,
>> and nobod
23 matches
Mail list logo
