"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>>> On what platforms does ioctl() fail?
>
>> On ssh for example.
>
> That'd certainly be a showstopper if true, but it seems to be okay for
> me. ssh'ing from an xte
Bruce Momjian wrote:
For example, if I want to send wide psql output in email, right now I
just send it wide or use \x. With 'wrapped' I can set it to 72 columns
and get something I can email to people. I could copy it from my
screen, but if the output is more than a screen full it is much har
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > We have discussed having a formatting mode where aligned output switches
> > to expanded output when the row is too wide. One idea would be to
> > create an 'auto' mode that would display in aligned, or wrapped if that
> > doesn't fit, or expanded
Bruce Momjian wrote:
interactive mode. In fact, it is hard to justify our current
interactive behavior of a row just overflowing the screen width and
moving to the next line. We have gotten used to it, but it is certainly
not very user-friendly.
+1
We have discussed having a formatting mo
Robert Treat <[EMAIL PROTECTED]> writes:
> Perhaps a better option would be to implement Merge per spec, and then
> implement a "replace into" command for the oltp scenario. This way you keep
> the spec behavior for the spec syntax, and have a clearly non-spec command
> for non-spec behavior.
On Apr 24, 2008, at 1:01 PM, Steve Atkins wrote:
I've been chatting with the Trolltech folks about the
implementation of the Qt wrapper around libpq, and the issue of how
to properly do metadata queries came up. That is things like "What
are the column names and types of the primary key of t
Bruce Momjian wrote:
> > Trying to join the two decisions means that nobody will be happy. If you ssh
> > in you won't get wrapped format, if you redirect to a file and specify
> > wrapped
> > format explicitly you'll be frustrated that you're still not getting it. And
> > if you do want those thi
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > I am not excited about 'wrapped-interactive' and 'wrapped-all' formats.
> > Do you have some other idea in mind?
>
> Some other idea for the name of it? Not particularly. I like your later
> suggestion of "auto". Perhaps ju
On Thursday 24 April 2008 12:19, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > That really strikes me as taking the "MySQL route". If push comes to
> > shove, I'll take a MERGE with race conditions over no merge at all,
> > but I think it's very important that it does the right thing.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> On what platforms does ioctl() fail?
> On ssh for example.
That'd certainly be a showstopper if true, but it seems to be okay for
me. ssh'ing from an xterm window, and running psql on the remote side,
I c
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I am not excited about 'wrapped-interactive' and 'wrapped-all' formats.
> Do you have some other idea in mind?
Some other idea for the name of it? Not particularly. I like your later
suggestion of "auto". Perhaps just "wrapped" and "auto"?
> I can't
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> On what platforms does ioctl() fail?
On ssh for example.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Apr 24, 2008, at 2:22 PM, Tom Lane wrote:
Steve Atkins <[EMAIL PROTECTED]> writes:
On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote:
I believe the information_schema is standard.
Standard, but woefully incomplete (by design).
Sure, because it's restricted to standardized concepts.
Steve Atkins <[EMAIL PROTECTED]> writes:
> On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote:
>> I believe the information_schema is standard.
> Standard, but woefully incomplete (by design).
Sure, because it's restricted to standardized concepts. Do the adapters
in question need to obtain inf
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Peter Eisentraut wrote:
> > >
> > > I think it is best not to look at $COLUMNS at all. If the output is to a
> > > terminal, then use ioctl to query the terminal. And provide a \pset
> > > command
> > > to set a width explicitly, which can a
Bruce Momjian escribió:
> Peter Eisentraut wrote:
> >
> > I think it is best not to look at $COLUMNS at all. If the output is to a
> > terminal, then use ioctl to query the terminal. And provide a \pset
> > command
> > to set a width explicitly, which can apply in all cases.
>
> Yes, that is
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > I think the API in the patch is the best I am going to do to keep
> > everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> > also tell it the width you want. Most interactive users are going to
> > set '
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Greg's suggestion is to use $COLUMNS if the width can't be determined
> > because the output is not directly to the screen. ?$COLUMNS is updated
> > by many shells.
>
> I think it is best not to look at $COLUMNS at all. If the output is to a
> t
Bruce Momjian wrote:
> Greg's suggestion is to use $COLUMNS if the width can't be determined
> because the output is not directly to the screen. $COLUMNS is updated
> by many shells.
I think it is best not to look at $COLUMNS at all. If the output is to a
terminal, then use ioctl to query the t
Bruce Momjian wrote:
> 'ls' and 'ls | more' generate different outputs, and I have never heard
> anyone call that "bunk".
bunk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I think the API in the patch is the best I am going to do to keep
> everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> also tell it the width you want. Most interactive users are going to
> set 'wrapped' and never set the width
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > 'ls' and 'ls | more' generate different outputs, and I have never heard
> > anyone call that "bunk".
>
> The analogue of that would be making psql default to wrapped mode if isatty is
> true and normal mode if it's false. I
[EMAIL PROTECTED] (Decibel!) writes:
> On Apr 22, 2008, at 1:17 PM, Gregory Stark wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>
>>> As I've said elsewhere, we could have it lock each row, its just more
>>> overhead if we do and not necessary at all for bulk data merging.
>>>
>>> I'll pres
On Thu, 2008-04-24 at 12:19 -0400, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > That really strikes me as taking the "MySQL route". If push comes to
> > shove, I'll take a MERGE with race conditions over no merge at all,
> > but I think it's very important that it does the right t
Aidan Van Dyk wrote:
-- Start of PGP signed section.
> * Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]:
>
> > I am confused exactly what people want changed in the patch. Some want
> > no control over wrapping in file output, and others want $COLUMN to
> > control column file output. The onl
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> 'ls' and 'ls | more' generate different outputs, and I have never heard
> anyone call that "bunk".
The analogue of that would be making psql default to wrapped mode if isatty is
true and normal mode if it's false. I wouldn't be entirely against that b
* Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]:
> I am confused exactly what people want changed in the patch. Some want
> no control over wrapping in file output, and others want $COLUMN to
> control column file output. The only person I am seeing code from is
> Greg Stark, but I think mos
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > You are going to need to find community members who support your
> > > analysis if you want to make any headway in changing the patch.
> >
> > Let's turn that around, shall we? I think at this point it's *you*
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > You are going to need to find community members who support your
> > analysis if you want to make any headway in changing the patch.
>
> Let's turn that around, shall we? I think at this point it's *you*
> that are standing alone and
Bruce Momjian <[EMAIL PROTECTED]> writes:
> You are going to need to find community members who support your
> analysis if you want to make any headway in changing the patch.
Let's turn that around, shall we? I think at this point it's *you*
that are standing alone and need to find someone who ag
Added to TODO:
* Allow prepared transactions with temporary tables created and dropped
in the same transaction, and when an ON COMMIT DELETE ROWS temporary
table is accessed
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php
On Apr 24, 2008, at 11:12 AM, Joshua D. Drake wrote:
On Thu, 24 Apr 2008 11:01:13 -0700
Steve Atkins <[EMAIL PROTECTED]> wrote:
I've been chatting with the Trolltech folks about the implementation
of the Qt wrapper around libpq, and the issue of how to properly do
metadata queries came up. Th
On Thu, 24 Apr 2008 11:01:13 -0700
Steve Atkins <[EMAIL PROTECTED]> wrote:
> I've been chatting with the Trolltech folks about the implementation
> of the Qt wrapper around libpq, and the issue of how to properly do
> metadata queries came up. That is things like "What are the column
> names
I've been chatting with the Trolltech folks about the implementation
of the Qt wrapper around libpq, and the issue of how to properly do
metadata queries came up. That is things like "What are the column
names and types of the primary key of this table, and what index
enforces it?" or "What
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 25, 2008 at 3:46 AM, Tom Lane wrote:
> alter table t1 add column f2 int not null;
>
> transformAlterTableStmt will produce an AT_AddColumn subcommand
> containing a ColumnDef with is_not_null = false, followed by an
> AT_SetNotNull sub
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > My point is that we should do what most people _expect_, and the
> > majority of people here have stated they don't think wrap should modify
> > the file output _by_ _default_.
> >
> > People who want a specific width for fil
I wrote:
> So somehow the constraint-validation code isn't getting applied in
> this case. I suspect you'll find it's a pretty localized fix.
I traced through this and found that for
alter table t1 add column f2 int not null;
transformAlterTableStmt will produce an AT_AddColumn subcommand
conta
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> My point is that we should do what most people _expect_, and the
> majority of people here have stated they don't think wrap should modify
> the file output _by_ _default_.
>
> People who want a specific width for files should be setting their
> desire
Added to TODO:
> o Impove COPY performance
>
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php
---
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki, are there any TODO items here?
I wrote:
> I think the bug here is that ADD COLUMN NOT NULL has to fail if
> there's not a default expression supplied (except maybe we could
> allow it if the table contains no rows). ISTM we got this right
> in the past, wonder why it's not working now ...
Hm, we do get it right if PRIMARY KEY
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 25, 2008 at 2:27 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
> > transformIndexConstraint sets the is_not_null flag on the ColumnDefs
> > associated with the primary key. That works great in a CREATE TABLE
> > context, but in ADD COL
Merlin Moncure wrote:
With an eye towards sideband utility, we are suggesting:
PQcopyResult(PGresult *dest, const PGresult *src, int numAttributes,
PGresAttDesc *attDescs, int options);
Small correction on that prototype.
PGresult *
PQcopyResult(const PGresult *src, int numAttributes,
PGre
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Is this TODO item done?
> > >>> * Allow index scans to return matching index keys
> > >>>
> > >>> http://archives.postgresql.org/pgsql-h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ah, OK, exactly what should the TODO item text be? Can you modify the
> TODO? I don't understand the TODO text I had.
What I thought the TODO was about was extending the indexam API so that
the actual key values stored in the index could be retrieved (
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Well, for these two:
> * For Highly Non-Unique Data we can use Duplicate Compression
> * Multi-Column Leading Value Compression - if you have a multi-column
> You don't need any new logic at all. If _bt_compare says they're equal
> you can compa
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Peter Eisentraut wrote:
> > >> Well, the feature is labeled "psql wraps at window width". If the
> > >> output
> > >> isn't on a window, then it shouldn't wrap.
> >
> > > \pset columns will wrap to the sp
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this TODO item done?
> >>> * Allow index scans to return matching index keys
> >>>
> >>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
> >>
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Well, the feature is labeled "psql wraps at window width". If the output
> >> isn't on a window, then it shouldn't wrap.
>
> > \pset columns will wrap to the specified width for file output.
>
> I agree
Well, for these two:
> >> * For Highly Non-Unique Data we can use Duplicate Compression
> >> * Multi-Column Leading Value Compression - if you have a multi-column
You don't need any new logic at all. If _bt_compare says they're equal
you can compact them.
The long similar case is harder, ISTM the
Gregory Stark wrote:
> >> b) If you dump to a file it will still respect COLUMNS. This might be a bit
> >>weird since bash sets COLUMNS so your file width will be based on the
> >> size
> >>of your terminal. But people also do things like COLUMNS=120 psql -o f
> >> ...
> >
> > No, that wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Well, the feature is labeled "psql wraps at window width". If the output
>> isn't on a window, then it shouldn't wrap.
> \pset columns will wrap to the specified width for file output.
I agree with Peter: that's a seriously
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> transformIndexConstraint sets the is_not_null flag on the ColumnDefs
> associated with the primary key. That works great in a CREATE TABLE
> context, but in ADD COLUMN, when we haven't created the column yet,
> this means that the column is created with
On Apr 24, 2008, at 10:43 AM, Bruce Momjian wrote:
Bruce asked if these should be TODOs...
Index compression is possible in many ways, depending upon the
situation. All of the following sound similar at a high level, but
each
covers a different use case.
* For Long, Similar data e.g. Text w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this TODO item done?
>>> * Allow index scans to return matching index keys
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
>>
>> We've done as much as we want to
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Uh, if you do that I am not sure what the user would want. I duplicated
> what we do with PAGER and unless there is a clear mandate I think we
> should keep the wrapping detection consistent with that; we have gotten
> no complaints. Pager will not
On Thu, 2008-04-24 at 11:43 -0400, Bruce Momjian wrote:
> > Index compression is possible in many ways, depending upon the
> > situation. All of the following sound similar at a high level, but each
> > covers a different use case.
> >
> > * For Long, Similar data e.g. Text we can use Prefix Comp
Decibel! <[EMAIL PROTECTED]> writes:
> That really strikes me as taking the "MySQL route". If push comes to
> shove, I'll take a MERGE with race conditions over no merge at all,
> but I think it's very important that it does the right thing. Just
> because the spec doesn't say anything about
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this TODO item done?
> > * Allow index scans to return matching index keys
>
> > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
>
> We've done as much as we want to do of what that message sugges
On Apr 23, 2008, at 12:31 AM, Greg Smith wrote:
Jim threw out that you can just look at the page hit percentages
instead. That's not completely true. If you've had some nasty
query blow out your buffer cache, or if the server has been up a
looong time and the total stas don't really reflect
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this TODO item done?
> * Allow index scans to return matching index keys
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
We've done as much as we want to do of what that message suggests,
but it seems to have
On Apr 22, 2008, at 3:20 PM, Martijn van Oosterhout wrote:
On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
But no matter how this is done, I think we need to handle the race
conditions, and handle them by default. If people *really* know what
they're doing, they can disable the row lo
According to the zic database, SGT is the recognized abbreviation for
Singapore time, and there are no other conflicting uses. I wonder why
it isn't in either the Default or Asia lists ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Peter Eisentraut wrote:
> Am Donnerstag, 24. April 2008 schrieb Gregory Stark:
> > b) If you dump to a file it will still respect COLUMNS. This might be a bit
> > ? ?weird since bash sets COLUMNS so your file width will be based on the
> > size of your terminal. But people also do things like COLUM
Simon Riggs wrote:
> > > Many users would be very interested if we could significantly reduce the
> > > size of the main index on their largest tables.
> >
> > Yes, basically GIT allows index compression for clustered tables, and
> > stated that way it is clear it would be a big feature if we had
Is this TODO item done?
* Allow index scans to return matching index keys
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 24, 2008 at 7:13 PM, Richard Huxton wrote:
> Kaloyan Iliev wrote:
> > r=# CREATE TABLE test( a text, b int);
> > CREATE TABLE
> > r=# INSERT INTO test VALUES ('test',1);
> > INSERT 0 1
> > r=# ALTER TABLE test ADD COLUMN id INT NOT NULL P
Am Mittwoch, 23. April 2008 schrieb Andrew Dunstan:
> No, I mean you could put it in your psql prompt.
>
> 8.3 dbname>
You can put variables in your prompt. The VERSION variable exists, but it is
a bit verbose. Perhaps it can be trimmed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Am Donnerstag, 24. April 2008 schrieb Gregory Stark:
> b) If you dump to a file it will still respect COLUMNS. This might be a bit
> weird since bash sets COLUMNS so your file width will be based on the
> size of your terminal. But people also do things like COLUMNS=120 psql -o f
> ...
Well, th
On Thu, 2008-04-24 at 23:25 +0900, Fujii Masao wrote:
> Hi,
>
> PITR always fails in finding the archived log file with wrong size. But,
> I think that we can continue PITR if .ready file of the same name exists
> in XLOGDIR/archive_status, ie the complete file might exist in XLOGDIR.
>
> I want
Bruce Momjian escribió:
> > b) If you dump to a file it will still respect COLUMNS. This might be a bit
> >weird since bash sets COLUMNS so your file width will be based on the
> > size
> >of your terminal. But people also do things like COLUMNS=120 psql -o f
> > ...
>
> No, that will m
Fujii Masao <[EMAIL PROTECTED]> writes:
> PITR always fails in finding the archived log file with wrong size.
If the archived file is actually broken like that, it hardly seems
prudent to keep going ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> Earlier I suggested -- and nobody refuted -- that we should follow the
> >> precedents of ls and man and other tools which need to find the terminal
> >> width: Explicitly set width takes precedence alw
Hi,
PITR always fails in finding the archived log file with wrong size. But,
I think that we can continue PITR if .ready file of the same name exists
in XLOGDIR/archive_status, ie the complete file might exist in XLOGDIR.
I want to modify the implementation of PITR a little as follows.
- In PITR
We are trying to clean up the object hooks patch (on the libpq side)
in time for the May commit fest. The last version we posted is here:
http://www.nabble.com/libpq-object-hooks-patch-to16707707.html
Everything for the most part works ok but there is a problem with the
function 'PQmakeResult' wh
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote:
>> Index compression is possible in many ways, depending upon the
>> situation. All of the following sound similar at a high level, but each
>> covers a different use case.
>
> True,
Simon Riggs <[EMAIL PROTECTED]> wrote:
> * For Highly Non-Unique Data we can use Duplicate Compression
> The latter is the technique used by Bitmap Indexes. Efficient, but not
> useful for unique/nearly-unique data
I heard that GIN has already had duplicate-compression feature.
http://www.sai.m
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> Earlier I suggested -- and nobody refuted -- that we should follow the
>> precedents of ls and man and other tools which need to find the terminal
>> width: Explicitly set width takes precedence always, if it's not explicitly
On Thu, 2008-04-24 at 13:13 +0200, Martijn van Oosterhout wrote:
> On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote:
> > Index compression is possible in many ways, depending upon the
> > situation. All of the following sound similar at a high level, but each
> > covers a different use c
On Tue, 2008-02-26 at 09:08 +, Simon Riggs wrote:
> I very much like the idea of index merging, or put another way: batch
> index inserts. How big do the batch of index inserts have to be for us
> to gain benefit from this technique? Would it be possible to just buffer
> the index inserts insi
On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote:
> Index compression is possible in many ways, depending upon the
> situation. All of the following sound similar at a high level, but each
> covers a different use case.
True, but there is one significant difference:
> * For Long, Simil
On Wed, 2008-04-23 at 19:43 -0700, Ron Mayer wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
> >>> To be acceptable, a GIT patch would have to be optional and it
> >>> ...
> > I was considering a new pg_index column. Or e
Kaloyan Iliev wrote:
Hi,
I find something very interesting which I think is a bug and I want to
discuss it.
---
Here is the example1:
1.I create a table without PK;
2.Insert 1 row;
3.I ADD PK;
4.When I select all ID's are
On Wed, 2008-04-23 at 22:26 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > GIT significantly reduces the size of clustered indexes, greatly
> > improving the number of index pointers that can be held in memory for
> > very large indexes. That translates directly into a reduction in I/O for
>
Interesting. Does this mean that down the road a postgis index
might be GIT-ified?
Only if GiST will support GIT, but I don't follow on this discussion. In any
case, GIT on GiST will not be so effective as on Btree, because GiST doesn't
guarantee that all close values will be close in index:
84 matches
Mail list logo
