On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
Does anyone have any other suggestions on how to make sure autovacuum
does not run in freeze mode?
Can you run in single user mode?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, 2011-03-29 at 21:43 -0300, Alvaro Herrera wrote:
I think it would be better to have
some sort of option to disable autovacuum completely which would be used
only during pg_upgrade.
Sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Fri, 2011-03-18 at 08:27 -0400, Robert Haas wrote:
On Thu, Mar 17, 2011 at 6:00 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2011-03-16 at 13:35 -0400, Robert Haas wrote:
2. If a query cancel interrupt is received (pg_cancel_backend or ^C),
then cancel the sync rep wait and issue
On Fri, 2011-03-18 at 10:27 -0400, Robert Haas wrote:
ERRCODE_(WARNING_?)REPLICATION_WAIT_CANCELLED
...which might have something to recommend it.
Works for me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
like it should -- this is the kind of thing that the
client is likely to care about, and may want to handle specially.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
/msg01279.php
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to take, and
we'll end up with a lot of unintuitive and error-prone operators.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2011-03-05 at 18:33 -0500, Bruce Momjian wrote:
I am seeing the following compile problem with gmake -j2:
For what it's worth, I'm still seeing this problem too:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00123.php
I can reproduce it every time.
Regards,
Jeff
and switchover, right? At
least Slony makes such a distinction, as well.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, especially at
MemoryContextStats(TopMemoryContext), but was not rewarded.
Where is all of that memory going during recovery? Recovery shouldn't
use much memory at all, as far as I can tell.
What's even allocating memory at all?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
? That would allow range types and exclusion constraints to be used
out-of-the-box in 9.2.
Only if you think it's reasonable to put it in core, of course. If
extensions are easy enough to install, maybe that's not really
necessary.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote:
On Wed, February 9, 2011 09:35, Jeff Davis wrote:
Updated patch.
The operators and -|- have the following behavior with empty ranges:
testdb=# select '-'::int4range range(200,300);
ERROR: empty range
testdb=# select
of
-|- means adjacent (touching but not overlapping)
I'm open to suggestion about how those behave with empty ranges.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
is that we should let the operation proceed as far as it is
well-defined, and no further; and I think that means empty ranges should
be allowed.
Thoughts? Do the benefits outweigh the costs?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
.
Or, there are always check constraints...
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(at least not in a practical
way that I can tell).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote:
On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis pg...@j-davis.com wrote:
Similarly, intersection of ranges is somewhat analogous to
multiplication of numbers.
I had a feeling that we might be going in this direction. It strikes
me
testing only if you're
lucky.
Now, I agree that lack of closure on UNION exhibits many of the problems
that I am pointing out related to forbidding empty ranges. However, I'm
not sure if that means we should give up on either.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
, but I
can see where ranges could potentially be more powerful.
Ranges support infinite boundaries, but do not support NULL (previous
discussion concluded that NULL boundaries were likely to be confusing
and served no obvious use case not handled by infinity).
Regards,
Jeff Davis
On Fri, 2011-02-11 at 15:14 -0500, Robert Haas wrote:
On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis pg...@j-davis.com wrote:
Well, there is a certain amount of localized clarity, I will agree with
that. The complexity comes when you accidentally rely on some
transformation which seems
On Thu, 2011-02-10 at 12:04 -0500, Tom Lane wrote:
Erik Rijkers e...@xs4all.nl writes:
On Wed, February 9, 2011 09:35, Jeff Davis wrote:
Updated patch.
I just wanted to mention that this latest patch doesn't quite apply as-is,
because of catversion changes.
Just a note: standard
it will need to be
reloaded to work with the latest.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2011-02-10 at 09:46 -0500, Robert Haas wrote:
On Tue, Feb 8, 2011 at 7:58 PM, Jeff Davis pg...@j-davis.com wrote:
On the flip side, if we don't provide review to WIP patches during the
3rd commitfest, how do we expect to get anything close to committable on
the 1st commitfest
will think it's not very SQL-like.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, I'll implement this approach. 22 bytes represents 37.5% overhead
above the good ol' PERIOD data type (a lean 16 bytes), but we can make
up some of that if using unbounded ranges. For instance, a half-open
range like [5, INF) would only take 14 bytes.
Regards,
Jeff Davis
--
Sent via pgsql
* SQL length function --immutable/stable/volatile?
As always, my repo is here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Regards,
Jeff Davis
rangetypes-20110208.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers
a chance for 9.2 as well. Or, maybe some
other features might find it useful, like partitioning or audit logs.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-- except maybe as a rewrite like you
say.
One thing you might try is a functional index on (range(whensit)) and
then do: where '...' @ range(whensit).
Does that work for you?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, 2011-02-09 at 18:07 -0500, Chris Browne wrote:
rangetest@localhost- create index i2 on some_data (range(whensit));
CREATE INDEX
If you make this a GiST index, it should work.
The rewrites so that it can use a btree are an interesting idea though.
Regards,
Jeff Davis
to do something similar
for range types -- especially if there are alternative range types for a
given base type.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
If CREATE TYPE already has an options list, it seems a little strange to
add grammar to support this feature. USING doesn't seem to mean a lot,
except that we happen to use it in other contexts to mean operator
class.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
. Without some checkpoint, the chances that everyone agrees with all
of these decisions at the beginning of the next commitfest is zero.
Is the commitfest not the right place to do this? If not, then when?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
, but in addition to some cleanup, any patch
like this at least requires some discussion. It's a language change
we'll be supporting for a long time.
At minimum, we're a couple hundred emails shy of a real consensus on the
naming ;)
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
concern is that, aside from code, my patch didn't make much progress
this commitfest. And the code progress was mostly me working through my
own TODO list on things like GiST support -- which didn't represent any
real decisions, it was mostly just a matter of code.
Regards,
Jeff Davis
of the next cycle?
Although it doesn't
feel like it at the moment, we have actually made great strides in
absorbing large patches.
I agree completely.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Tue, 2011-02-08 at 09:10 -0800, Jeff Davis wrote:
On Mon, 2011-02-07 at 18:23 +0100, Dimitri Fontaine wrote:
I would think
CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
The USING clause is optional, because you generally have a default btree
opclass for the datatype
contexts are functions called that get_fn_expr_argtype()
might fail; and are the above constructors at risk for that? Is there a
better way?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
bound, inclusive upper bound
I tried to clarify that section.
Thank you for the review! Updated patch forthcoming.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Wed, 2011-02-09 at 15:39 +0900, Itagaki Takahiro wrote:
On Wed, Feb 9, 2011 at 14:50, Jeff Davis pg...@j-davis.com wrote:
1.
The obvious constructor would be:
range(1, 10)
But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
all 4, and it's not obvious how to do
, but an updated
patch should come soon.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2011-02-07 at 13:33 +0100, Dimitri Fontaine wrote:
Hi,
Jeff Davis pg...@j-davis.com writes:
* Should pg_range reference the btree opclass or the compare function
directly?
I would say yes. We use the btree opclass in other similar situations.
Ok, but what should
=7841a22648c3f4ae46f674d7cf4a7c2673cf9ed2
What does PredicateLockTuple do that needs a share lock? Does a pin
suffice?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
useful with exclusion constraints
out-of-the-box. This should be left for later, I'm just including this
for the archives so it doesn't get lost.
Regards,
Jeff Davis
rangetypes-20110205.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Sun, 2011-01-30 at 17:14 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote:
postgres=# select '[18,20]'::numrange @ 19;
ERROR: operator does not exist: numrange @ integer
LINE 1: select '[18,20]'::numrange @ 19;
^
HINT
that way once I
looked at the code with the changes you suggested.
Yes, I like those changes.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
similar case to some I found elsewhere that elog was
used.
Looks good. It also looks like it contains a bugfix for subtransactions,
right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
recently suggested using an
infomask bit to mean frozen, rather than actually removing the xid, to
save the xid as forensic information. If that were to happen, your code
would be reading an xid that may have been re-used.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
I don't think this function really cares about the visibility with
respect to the current snapshot, right?
What it cares about is whether some other particular top level
transaction wrote
.
And I don't think the original switch statement I posted did the right
thing for HEAPTUPLE_LIVE. I think that case needs to account for the
visible flag (if it's live but not visible, that's the same as
insert-in-progress for your purposes).
Regards,
Jeff Davis
--
Sent via pgsql
that's a safe assumption. If there is some kind of noticeable
difference in conflict rates or runtime, that probably indicates a bug
in the new or old code.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to
complete a thorough review. If you have other patches to review/commit
then I will still be making progress reviewing SSI.
However, I would recommend leaving yourself some time to think on this
one if you don't already understand the design well.
Regards,
Jeff Davis
--
Sent via pgsql
;
^
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.
It's because it doesn't know the type on the right side, and assumes
it's an int4.
select '[18,20]'::numrange @ 19.0;
works.
Regards,
Jeff
should be improved to handle spaces and quoting better
* Should btree_gist be pulled into core to make it easier to use
exclusion constraints with range types?
* Typmod (optional)
Regards,
Jeff Davis
rangetypes-20110130.patch.gz
Description: GNU Zip compressed data
--
Sent via
://archives.postgresql.org/message-id/23698.1295566...@sss.pgh.pa.us
We don't need a perfect solution for 9.1, but it would be nice if we had
a viable plan for 9.2.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.
To drop the one you created, do:
DROP TYPE public.numrange;
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
seems like a
good idea.
OK, I'll change intrange to int4range, and add int8range. int2range
doesn't seem useful, though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
are arbitrarily long, and don't have any defined step, so
that means an infinite number of keys. GiST works better for that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Sat, 2011-01-29 at 14:42 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
Also, if I try the same, but with a different name for the type, I get
the same error. Why does that restriction exist? Can't you have
types which
On Tue, 2011-01-25 at 15:22 -0600, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
I think just annotating RWConflict.in/outLink and
PredTranList.available/activeList with the types of things they
hold would be a help.
Also, you say something about RWConflict and when
is necessary
for GiST.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
completion. GiST is by far the most amount of effort
remaining that I'm aware of. Comments about the API, naming,
representation, interface, funcationality, grammar, etc. are welcome.
Regards,
Jeff Davis
rangetypes-20110127.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql
this committed, because I'm looking forward to this feature. And I
certainly think that you and Dan have applied the amount of planning,
documentation, and careful implementation necessary for a feature like
this.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
/outLink and
PredTranList.available/activeList with the types of things they hold
would be a help.
Also, you say something about RWConflict and when the structure is not
in use. Can you elaborate on that a bit?
I'll address the rest of your comments in a later email.
Regards,
Jeff Davis
,
it's just going to go to sleep in that case anyway; so why not look for
an opportunity to get a safe snapshot right away?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Fri, 2011-01-21 at 12:31 -0500, Robert Haas wrote:
On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis pg...@j-davis.com wrote:
New patch. I added a lot of generic range functions, and a lot of
operators.
There is still more work to do, this is just an updated patch. The
latest can be seen
the write transactions, and progress will
be made. And if the system is idle, they should see identical data.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Jeff Davis
rangetypes-20110119.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
into repeatable read.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
proposal for NULL range boundaries?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-thinking the null semantics.
3. perhaps fix typmod
4. documentation
5. more tests
7. better parser
Regards,
Jeff Davis
rangetypes-20110114.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a63d83f427fbce97a6cea0db2e64b0eb8435cd10
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not worth complicating the code at this stage. KISS again :)
OK.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the
boundaries of the range is missing (NULL or INF), and it would
complicate the code a little. Thoughts?
Regards,
Jeff Davis
rangetypes-20110110.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
of 2PC and NOTIFY.
I don't expect this to be a huge roadblock for the feature though. It
seems fairly contained. I haven't read the 2PC code either, but I don't
expect that you'll need to change the rest of your algorithm just to
support it.
Regards,
Jeff Davis
--
Sent via pgsql-hackers
, if the WAL referenced in the backup_label
does not exist, then it PANICs with a HINT to tell you to remove the
backup_label.
Is this an opportunity to solve these problems and simplify the code?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
make some fairly minor changes, like making a file on
the primary and telling users to exclude it from any base backup. The
danger, of course, is that they do copy it, and their backup is
compromised.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
are restoring a backup, and it's really a primary that
crashed, then you run into one of the two problems that I mentioned
(which are less severe than corruption, but very annoying).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
-ux.asterdata.local
It's gotten much worse recently, where changing a c file seems to
require multiple top-level make install commands to take effect (as
Tom describes). I don't think it's limited to the access/ subdirectory,
though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
could publish a sunset one release in
the future.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
was it eliminated? If the type output function got the type OID,
would it be enough to use fn_expr_get_argtype() for the other generic
functions?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
much, anyway?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
much, anyway?
I'd be really
On Sat, 2011-01-08 at 13:05 -0800, Jeff Davis wrote:
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4
On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags
. These functions are
tied to the operator, so it would be awkward to try to connect it to the
GiST support functions. Also, it doesn't seem to be an exact fit,
because the RESTRICT function is used to compute the selectivity as of
right now using current statistics.
Regards,
Jeff Davis
--
Sent via
will be as well. Not getting
them together might be the answer.
We may end up combining all of these concepts into type interfaces
later. Now that we have multiple potential users of type interfaces, it
will be easier to design type interfaces to work well for all of them.
Regards,
Jeff Davis
On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote:
The current design for range types doesn't ask for add or subtract.
Although it might be interesting to try to use such an interface for
range types, it introduces a lot of complexity and makes it easier to
cause subtle problems (consider
with a range type, there's no
way to tell which range type to pick given the window function syntax
(multiple range types could be defined over the same subtype).
I think the interface question should be addressed more directly with a
type interfaces patch.
Regards,
Jeff Davis
--
Sent via
simpler on the user (and
allows non-C functions). But perhaps an efficiency argument could be
made for the former because it could avoid one round of
deserialize/reserialize when the representation is not already in
canonical form.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote:
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to define math
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
2011/1/4 Jeff Davis pg...@j-davis.com:
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those
On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best
of different
opinions), so it was not included in this design. Similarly, I am
leaning away from lots of user-specified options unless there is a real
use case.
Any suggestions or comments welcome.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
notes.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to throw another idea out there, perhaps we could change the
behavior based on whether the page is already dirty or not. I haven't
thought this through, but it might be an interesting approach.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
might choose one of these more creative solutions that breaks the rules
in controlled ways, understanding the trade-offs. If only bulk loading
is affected, we might choose to address that case directly.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
701 - 800 of 1608 matches
Mail list logo
