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
anyone actively working on the bitmap index patch nor
On Tue, 8 Apr 2008, Heikki Linnakangas wrote:
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 anyone
[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 nobody
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).
In
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
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
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 anyone
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 as:
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.
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 index,
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
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 see doing col
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
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 235
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
better,
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 and/or
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 an
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 of
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
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.
I think
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 an
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 do
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 they
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 lifecycle:
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 for more work
25 matches
Mail list logo
