On Tue, 2011-03-01 at 22:56 +, Simon Riggs wrote:
> On Tue, 2011-03-01 at 12:42 -0800, Josh Berkus wrote:
> > > That response is just dodging the hard question, so whatever. Tom's
> > > cleanup is not going to break things, or at least it's going to fix
> > > more than it breaks on net. Sync
Thanks, Tom !
Oleg
On Wed, 2 Mar 2011, Tom Lane wrote:
Teodor Sigaev writes:
[ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards, tom lane
Teodor Sigaev writes:
> [ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Tue, 2011-03-01 at 12:42 -0800, Josh Berkus wrote:
> > That response is just dodging the hard question, so whatever. Tom's
> > cleanup is not going to break things, or at least it's going to fix
> > more than it breaks on net. Sync rep, on the other hand, is going to
> > do the opposite, proba
On Tue, Mar 1, 2011 at 4:58 PM, Robert Haas wrote:
>
> So where is the new patch, and the test reports from all the people
> who found problems in the last version?
>
Simon do this in his public repo here:
git://github.com/simon2ndQuadrant/postgres.git
It has been just one day from this so i exp
On Tue, Mar 1, 2011 at 4:55 PM, Jaime Casanova wrote:
> On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas wrote:
>> Sync rep, on the other hand, is going to
>> do the opposite, probably by a large margin.
>>
>
> Are you sure of that? the code is very centralized and the bugs we
> found last week weren'
On Tue, Mar 1, 2011 at 3:40 PM, Robert Haas wrote:
> Sync rep, on the other hand, is going to
> do the opposite, probably by a large margin.
>
Are you sure of that? the code is very centralized and the bugs we
found last week weren't that difficult to address, the prove for that
is that Simon fix
> That response is just dodging the hard question, so whatever. Tom's
> cleanup is not going to break things, or at least it's going to fix
> more than it breaks on net. Sync rep, on the other hand, is going to
> do the opposite, probably by a large margin.
Well, we need to at least give Simon
Robert Haas writes:
> Bruce has been going through the open items for the past several weeks
> (at least) and tells me that he hasn't found very much. I'm not sure
> what your thought is on what's required to get us from here to beta,
> but I am thinking it could be done in a few weeks. With a c
On Tue, Mar 1, 2011 at 3:36 PM, Josh Berkus wrote:
>
>> That's still missing the point, which is that the code is unlikely to
>> be up to our usual standards at that point.
>
> I was talking about "when do we close the CF and start building an
> alpha", not synch rep particularly. Tom said he wan
> That's still missing the point, which is that the code is unlikely to
> be up to our usual standards at that point.
I was talking about "when do we close the CF and start building an
alpha", not synch rep particularly. Tom said he wants until Friday
anyway just for some cleanup.
--
On Tue, Mar 1, 2011 at 3:01 PM, Josh Berkus wrote:
> On 3/1/11 11:58 AM, Tom Lane wrote:
>> If we do hold up the release, I'll probably go back and reopen the
>> postgresql_fdw patch as well as btree_gist. So I won't run out of
>> things to do. But I'm not terribly satisfied with the decision-ma
On Tue, 2011-03-01 at 14:26 -0500, Robert Haas wrote:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
> >
> >>> Since we appear to be still holding the commitfest open for Sync Rep,
> >>> I guess this ought to get reviewed.
> >>
> >> Or else we should close the CommitFest and cut alpha4. Any
On Tue, Mar 1, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
>>> I'd say that if there's a plausible chance that Sync Rep will be
>>> committable by the end of *this* week (and I mean Friday not Sunday),
>>> I'm willing to wait that lon
On Tue, Mar 1, 2011 at 3:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
>>> Ideally, we want to have some binaries/packages for the "final alpha".
>>> Those broaden testing considerably.
>
>> When we have a version that needs that treatment, we
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
>> Ideally, we want to have some binaries/packages for the "final alpha".
>> Those broaden testing considerably.
> When we have a version that needs that treatment, we can simply call
> it beta1. If it's too half-baked for
On 3/1/11 11:58 AM, Tom Lane wrote:
> If we do hold up the release, I'll probably go back and reopen the
> postgresql_fdw patch as well as btree_gist. So I won't run out of
> things to do. But I'm not terribly satisfied with the decision-making
> process here.
OK, well, we gave it an extra 15 da
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
>> I'd say that if there's a plausible chance that Sync Rep will be
>> committable by the end of *this* week (and I mean Friday not Sunday),
>> I'm willing to wait that long for it. Otherwise, it's 9.2 material.
> I am quite
On Tue, Mar 1, 2011 at 2:52 PM, Josh Berkus wrote:
> Ideally, we want to have some binaries/packages for the "final alpha".
> Those broaden testing considerably.
When we have a version that needs that treatment, we can simply call
it beta1. If it's too half-baked for that, then I don't see the p
> As I understand it, it requires only the steps described here:
>
> http://wiki.postgresql.org/wiki/Alpha_release_process
>
> That all looks pretty straightforward, assuming you can log into
> developer.postgresql.org, which I can't. I think I remember having an
> ftp account at some point, bu
On Tue, Mar 1, 2011 at 2:38 PM, Magnus Hagander wrote:
>> Frankly, I think we should be aiming to get a beta out in April, not
>> another alpha.
>
> That would be good, but in order to get there, +1 for cutting a new
> alpha even if syncrep isn't ready for it yet. That way we can at least
> get so
On Tue, Mar 1, 2011 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>>> I think we can give Sync Rep until the 15th, given the pace of work on
>>> it. It is a major feature, and a complicated one.
>
>> Sure, but there are other features, m
Robert Haas writes:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>> I think we can give Sync Rep until the 15th, given the pace of work on
>> it. It is a major feature, and a complicated one.
> Sure, but there are other features, major and minor, that we have
> postponed to 9.2. In the
On Tue, Mar 1, 2011 at 20:26, Robert Haas wrote:
> On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>>
Since we appear to be still holding the commitfest open for Sync Rep,
I guess this ought to get reviewed.
>>>
>>> Or else we should close the CommitFest and cut alpha4. Anyone have
On Tue, Mar 1, 2011 at 2:12 PM, Josh Berkus wrote:
>
>>> Since we appear to be still holding the commitfest open for Sync Rep,
>>> I guess this ought to get reviewed.
>>
>> Or else we should close the CommitFest and cut alpha4. Anyone have an
>> opinion on which way to go?
>
> I think we can give
>> Since we appear to be still holding the commitfest open for Sync Rep,
>> I guess this ought to get reviewed.
>
> Or else we should close the CommitFest and cut alpha4. Anyone have an
> opinion on which way to go?
I think we can give Sync Rep until the 15th, given the pace of work on
it. It
On Tue, Mar 1, 2011 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane wrote:
>>> Given that it is a contrib module, I personally wouldn't object to it
>>> getting patched later, like during alpha or beta. But somebody's got
>>> to do the work, and I'
Robert Haas writes:
> On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane wrote:
>> Given that it is a contrib module, I personally wouldn't object to it
>> getting patched later, like during alpha or beta. But somebody's got
>> to do the work, and I've got a dozen higher-priority problems right now.
> W
I did a quick look at this patch. The major problem with it is of
course that it needs to be fixed for the recent extension-related
changes. I transposed the .sql.in changes into additions to
btree_gist--1.0.sql (attached), but haven't really sanity-checked
them beyond checking that the regressi
On Mon, Feb 28, 2011 at 2:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus wrote:
Since no one has stepped up to fix these issues, I have marked this
patch Returned with Feedback.
>
>>> This is just contrib/btree_GIST, yes?
>
>> Yes, core KNN
Robert Haas writes:
> On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus wrote:
>>> Since no one has stepped up to fix these issues, I have marked this
>>> patch Returned with Feedback.
>> This is just contrib/btree_GIST, yes?
> Yes, core KNN was committed by Tom during the November CommitFest.
Righ
On Mon, Feb 28, 2011 at 1:53 PM, Josh Berkus wrote:
>
>> Since no one has stepped up to fix these issues, I have marked this
>> patch Returned with Feedback.
>
> This is just contrib/btree_GIST, yes?
Yes, core KNN was committed by Tom during the November CommitFest.
--
Robert Haas
EnterpriseDB:
> Since no one has stepped up to fix these issues, I have marked this
> patch Returned with Feedback.
This is just contrib/btree_GIST, yes?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http:
On Fri, Feb 18, 2011 at 1:07 AM, Tom Lane wrote:
> There might be more issues, I haven't read the patch in detail.
> But anyway, I'm going to set it to Waiting on Author. I think it
> needs at least a day or so's work, and I can't put in that kind of
> time on it now.
Since no one has stepped up
Teodor Sigaev writes:
>> I've applied all of this, and written documentation for all of it,
> Thank you a lot
>> except for the contrib/btree_gist additions which still need to be
>> redone for the revised API (and then documented!). My patience ran out
> Done, btree_gist is reworked for a new A
I've applied all of this, and written documentation for all of it,
Thank you a lot
except for the contrib/btree_gist additions which still need to be
redone for the revised API (and then documented!). My patience ran out
Done, btree_gist is reworked for a new API.
I'm very sorry, but I'm ra
Martijn van Oosterhout writes:
> On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
>> [ thinks for a bit... ] One reason for having a different structure
>> would be if we needed to represent abstract semantics for some operators
>> that couldn't be associated with a btree opclass.
> One
On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
> [ thinks for a bit... ] One reason for having a different structure
> would be if we needed to represent abstract semantics for some operators
> that couldn't be associated with a btree opclass. This is clearly not
> an issue for what RA
Hitoshi Harada writes:
> 2010/12/27 Robert Haas :
>> As far as window functions go, we clearly need some kind of type
>> interface feature, but I am unclear whether we should sandwhich it
>> into the btree opclass machinery or whether it might be better to
>> create a whole separate concept just f
2010/12/27 Robert Haas :
> On Sun, Dec 26, 2010 at 2:41 PM, Tom Lane wrote:
>> Hitoshi Harada writes:
>>> Catching up tonight, I wonder I could propose to add ordering
>>> operators in btree, not in gist, for basic types.
>>
>> I thought about that for a bit while working on the knngist patch, bu
On Sun, Dec 26, 2010 at 2:41 PM, Tom Lane wrote:
> Hitoshi Harada writes:
>> Catching up tonight, I wonder I could propose to add ordering
>> operators in btree, not in gist, for basic types.
>
> I thought about that for a bit while working on the knngist patch, but
> couldn't really see any usef
Hitoshi Harada writes:
> Catching up tonight, I wonder I could propose to add ordering
> operators in btree, not in gist, for basic types.
I thought about that for a bit while working on the knngist patch, but
couldn't really see any useful application. In particular, I don't see
a way to shoeho
2010/12/4 Tom Lane :
> What we have at this point (pending contrib/btree_gist fixes) is
> nearest-neighbor searching capability for point columns. And
> trigram-based nearest-neighbor for text strings, if you install
> contrib/pg_trgm. That doesn't seem like a lot of return for the
> amount of wo
On Wed, Dec 22, 2010 at 8:04 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > 2010/9/13 Teodor Sigaev :
>> >> [updated patch]
>>
>> > I realize I'm repeating myself, but... this patch needs
>> > documentation. It's not optional.
>>
>> I've applied all of this, and written
Tom Lane wrote:
> Robert Haas writes:
> > 2010/9/13 Teodor Sigaev :
> >> [updated patch]
>
> > I realize I'm repeating myself, but... this patch needs
> > documentation. It's not optional.
>
> I've applied all of this, and written documentation for all of it,
> except for the contrib/btree_gis
On Sat, 4 Dec 2010, Greg Stark wrote:
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov wrote:
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons,
though.
So, we'll have rather complete set of knn-fied data typ
Dimitri Fontaine writes:
> Greg Stark writes:
>> I kind of assumed the natural client for KNN-gist was the tsearch full
>> text search indexes handling sorting by relevance. For example if I
>> search for "Postgres DBA" I should find documents where those words
>> appear adjacent first and docume
Greg Stark writes:
> I kind of assumed the natural client for KNN-gist was the tsearch full
> text search indexes handling sorting by relevance. For example if I
> search for "Postgres DBA" I should find documents where those words
> appear adjacent first and documents where the two words appear f
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov wrote:
> We'll sync contrib/btree_gist with current API. Also, we're thinking
> about distance for ltree, boxes, circles. I'm not sure about polygons,
> though.
> So, we'll have rather complete set of knn-fied data types.
I kind of assumed the natural
Thanks to all for patience !
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons, though.
So, we'll have rather complete set of knn-fied data types.
Oleg
On Sat, 4 Dec 2010, Tom Lane wrote:
Robert Haas writ
Robert Haas writes:
> 2010/9/13 Teodor Sigaev :
>> [updated patch]
> I realize I'm repeating myself, but... this patch needs
> documentation. It's not optional.
I've applied all of this, and written documentation for all of it,
except for the contrib/btree_gist additions which still need to be
On Tue, Nov 23, 2010 at 11:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
>>> It would be the first, because simply assigning another strategy number
>>> only satisfies one of the unique constraints on pg_amop. To allow
>>> arbitrary flexibilit
I wrote:
> We will probably *also* want to pass these details explicitly to the
> index AM, but that doesn't solve the problem that some catalog somewhere
> has to say what it is that the opclass can do.
... although having said that, the obvious question is why that catalog
has to be pg_amop. Ma
Robert Haas writes:
> On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
>> It would be the first, because simply assigning another strategy number
>> only satisfies one of the unique constraints on pg_amop. To allow
>> arbitrary flexibility here, we would have to include all components of
>> the
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
>>> I'm satisfied to say that only one sort order can be associated with a
>>> particular operator in a particular opclass, which is what would be
>>> implied by using AMO
Robert Haas writes:
> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
>> I'm satisfied to say that only one sort order can be associated with a
>> particular operator in a particular opclass, which is what would be
>> implied by using AMOP_SEARCH/AMOP_ORDER as the unique key component.
> Does
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote:
>>> On balance I'm inclined to leave the unique key as per previous proposal
>>> (with a "purpose" column) and add the which-sort-order-is-that
>>> information as payload c
Robert Haas writes:
> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote:
>> On balance I'm inclined to leave the unique key as per previous proposal
>> (with a "purpose" column) and add the which-sort-order-is-that
>> information as payload columns that aren't part of the key.
> This is probably O
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote:
> The reason I bring this up now is that it affects the decision as to
> what the unique key for pg_amop ought to be. Instead of having an
> enum "purpose" column, maybe we should consider that the unique key
> is (operator oid, opfamily oid, order
I wrote:
> As far as the syntax of CREATE/ALTER OPERATOR CLASS/FAMILY is concerned,
> I like Robert's proposal (OPERATOR ... FOR ORDER or FOR SEARCH) better
> than Teodor's, though we don't need the multiple-purposes-per-entry
> aspect of it. This is mainly because it looks more easily extensible
I've done some *very* preliminary review of this patch now. I think
that the way to move forward is to first commit the work surrounding
changes to pg_amop, including suitable changes to CREATE/ALTER OPERATOR
CLASS/FAMILY so that there's a way to put the new info into the table.
The system won't i
Robert Haas writes:
> That doesn't seem very hard on its face. The trick is what to do with
> that information once you've got it. As far as I can tell, you need
> to drill some kind of hole that lets you pass "additional details
> about the desired sort order" to the index AM.
We clearly need
On Sun, Nov 21, 2010 at 5:24 PM, Tom Lane wrote:
> I haven't spent any time on this patch yet (hope to start looking at it
> next week). As for your specific question above, I don't have a big
> problem with reusing ScanKey this way, but I do agree that using
> RestrictInfo for this would be a cr
Robert Haas writes:
> 2010/11/12 Teodor Sigaev :
>> My variants informs GiST by SK_ORDER flags and consistentFn looks at
>> strategy number (strategy numbers are different for different purposes).
> Yeah. At ten thousand feet, I think the open design question here is
> to what extent it's OK to
2010/11/12 Teodor Sigaev :
>> Slightly-more-fleshed out proof of concept patch attached, with actual
>> syntax, documentation, and pg_dump support added. This might be
>> thought of as a subset of the builtin_knngist_core patch, without the
>> parts that make it actually do something useful (which
Slightly-more-fleshed out proof of concept patch attached, with actual
syntax, documentation, and pg_dump support added. This might be
thought of as a subset of the builtin_knngist_core patch, without the
parts that make it actually do something useful (which is mostly
match_pathkey_to_index - wh
Robert, it is great you are taking this on. This is really a well-known
area of the code for you, but not so much for Teodor and Oleg, so I am
sure they appreciate your assistance.
---
Robert Haas wrote:
> On Sat, Oct 16, 2
2010/10/22 Teodor Sigaev :
>> You can define the additional argument as providing all of the extra
>> info about how the operator is being used, and, if it's being used for
>> ordering, the details of the requested order. What is your thinking
>> on the matter?
>
> Maby be useful, but it seems to
You can define the additional argument as providing all of the extra
info about how the operator is being used, and, if it's being used for
ordering, the details of the requested order. What is your thinking
on the matter?
Maby be useful, but it seems to me to be a bit overengineering for now.
2010/10/19 Teodor Sigaev :
>>> Thinking about it that way, perhaps we could add an integer column
>>> amop_whats_it_good_for that gets used as a bit field. That wouldn't
>>> require changing the index structure, although it might break some
>>> other things.
>
>> OPERATOR strategy_number ( op_type
combination of parameters is one that it can handle. I'm thinking
perhaps in lieu of a boolean, we can add another indexam method which,
if not InvalidOid, gets called when we're wondering about whether a
given clause is something that the index can order by. Although
knngist focuses on a the OR
Thinking about it that way, perhaps we could add an integer column
amop_whats_it_good_for that gets used as a bit field. That wouldn't
require changing the index structure, although it might break some
other things.
OPERATOR strategy_number ( op_type [ , op_type ] ) [ FOR { SEARCH |
ORDER } [,
3) 3-rd boolean column (amopopr, amopfamily, amoporder)
- could be two records per operator
+ operator could be used in both roles
+ strategy number could be different for different roles
How can #3 work at all? It's ignoring a couple of critical index
columns. In particular, I be
On Mon, Oct 18, 2010 at 04:13:04PM +0100, Mark Cave-Ayland wrote:
> David Fetter wrote:
>
> >>For my vote, I'd prefer either the Oid of a custom type or an array
> >>of Oid, Datum pairs - i.e. something we can extend in the future if
> >>required.
> >
> >This sounds a lot like a foreign key to ano
Robert Haas writes:
> On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut wrote:
>> Frankly, I have no idea what knngist has to do with any of this, as I
>> haven't followed that topic at all.
> Me neither, except for the fact that the PostGIS guys are interested
> in both things. I think this th
On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut wrote:
> On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
>> On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote:
>> > On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
>> >> Paul Ramsey wrote:
>> >>
>> >> >> So what kind of data
On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
> On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote:
> > On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
> >> Paul Ramsey wrote:
> >>
> >> >> So what kind of data structure would you like for a typmod?
> >> >
> >> > I'm a primi
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut wrote:
> On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
>> Paul Ramsey wrote:
>>
>> >> So what kind of data structure would you like for a typmod?
>> >
>> > I'm a primitive enough beast that just having 64-bits would make me
>> > happy.
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
> Paul Ramsey wrote:
>
> >> So what kind of data structure would you like for a typmod?
> >
> > I'm a primitive enough beast that just having 64-bits would make me
> > happy. As a general matter though, a bytea?
> >
> > P
>
> For my vot
David Fetter wrote:
For my vote, I'd prefer either the Oid of a custom type or an array
of Oid, Datum pairs - i.e. something we can extend in the future if
required.
This sounds a lot like a foreign key to another table. Are you not
proposing doing that because of performance considerations?
On Mon, Oct 18, 2010 at 11:41:06AM +0100, Mark Cave-Ayland wrote:
> Paul Ramsey wrote:
>
> >>So what kind of data structure would you like for a typmod?
> >
> >I'm a primitive enough beast that just having 64-bits would make me
> >happy. As a general matter though, a bytea?
> >
> >P
>
> For my vo
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer either the Oid of a custom type or an array of
Oid, Datum pairs - i.e. so
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> I still feel vaguely uneasy about the fact that the proposed patch
>> can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
>> more last night when I read Peter's patch to add collation support.
>
> Good poi
On Fri, Oct 15, 2010 at 9:39 PM, Robert Haas wrote:
> On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas wrote:
>> On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane wrote:
Perhaps we should think of pg_amop not so much
as a way to tell the AM what to do, but just a way to tell it what
operator
On Sat, Oct 16, 2010 at 6:13 PM, Paul Ramsey wrote:
> On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut wrote:
>> On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
>>> >> (And, if we are going to break everything
>>> > in sight, now would be a good time to think about changing typmod to
>>
On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut wrote:
> On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
>> >> (And, if we are going to break everything
>> > in sight, now would be a good time to think about changing typmod to
>> > something more flexible than one int32.)
>>
>> As someo
On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
> >> (And, if we are going to break everything
> > in sight, now would be a good time to think about changing typmod to
> > something more flexible than one int32.)
>
> As someone who is jamming geometry type, spatial reference number and
> d
>> (And, if we are going to break everything
> in sight, now would be a good time to think about changing typmod to
> something more flexible than one int32.)
As someone who is jamming geometry type, spatial reference number and
dimensionality into said 32bit typmod, let me say emphatically ..
On Fri, Oct 15, 2010 at 08:45:26PM -0400, Robert Haas wrote:
> But I'm also not sure how far this gets us with KNNGIST, where the
> issue is not the typmods but the auxilliary information about the
> context of the sort and/or whether this is a sort or qual.
ISTM there are two issues here. With Bt
On Fri, Oct 15, 2010 at 8:45 PM, Robert Haas wrote:
> On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane wrote:
>>> Perhaps we should think of pg_amop not so much
>>> as a way to tell the AM what to do, but just a way to tell it what
>>> operator is logically involved without relying on the name or OID.
>
On Fri, Oct 15, 2010 at 8:10 PM, Tom Lane wrote:
>> Perhaps we should think of pg_amop not so much
>> as a way to tell the AM what to do, but just a way to tell it what
>> operator is logically involved without relying on the name or OID.
>
> I already think of it that way ...
OK.
>>> Maybe we s
Robert Haas writes:
> On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane wrote:
>> Well, we cannot avoid changing pg_amop, or at least changing its
>> interpretation, because the current scheme simply can't represent
>> indexable operators that are used for anything except simple boolean
>> WHERE tests.
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> I still feel vaguely uneasy about the fact that the proposed patch
>> can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
>> more last night when I read Peter's patch to add collation support.
>
> Good poi
Robert Haas writes:
> I still feel vaguely uneasy about the fact that the proposed patch
> can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
> more last night when I read Peter's patch to add collation support.
Good point.
> We could possibly cram ASC/DESC and NULLS FIRST/LAS
On Fri, Oct 15, 2010 at 5:35 PM, Robert Haas wrote:
> On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane wrote:
>> BTW, have we discussed the idea of embedding the role in the strategy
>> number? For example, require regular operators to have strategy
>> numbers 1-, while ordering operators have num
On Fri, Oct 15, 2010 at 12:02 PM, Tom Lane wrote:
> BTW, have we discussed the idea of embedding the role in the strategy
> number? For example, require regular operators to have strategy
> numbers 1-, while ordering operators have numbers 1-1,
> leaving room for a couple more roles b
Teodor Sigaev writes:
> As I remember, there were several suggested designs:
> 1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype,
> amopstrategy,
> amoporder) to point kind of operator (search or order)
>+ saves one record for operator in pg_amop
>- operator could not be us
forward. Tom and I laid out a technical design back in January and I
still think it's a good one, even though I know you think it's silly.
We may just have to agree to disagree on this point.
As I remember, there were several suggested designs:
1) 5-th boolean column (amopfamily, amoplefttype,
On Tue, Oct 5, 2010 at 5:05 PM, Oleg Bartunov wrote:
> Are you sure postgres doesn't have limitation at all ? There are a lot ot
> them. Of course, there are limitation and limitation and we should avoid
> limitations, which will require incompatible changes in future in user's
> code, or which pr
Robert,
Are you sure postgres doesn't have limitation at all ? There are a lot ot them.
Of course, there are limitation and limitation and we should avoid limitations,
which will require incompatible changes in future in user's code, or which
prevent future improvements (getting rid limitation
1 - 100 of 113 matches
Mail list logo
