Re: [HACKERS] initdb and fsync

2012-03-13 Thread Jeff Davis
Patch attached. Now I feel much better about it. Most people will either have fadvise, a write cache (rightly or wrongly), or actually need the sync. Those that have none of those can use -N. Regards, Jeff Davis initdb-fsync-20120313.patch.gz Description: GNU Zip compressed data -- Sent

Re: [HACKERS] initdb and fsync

2012-03-12 Thread Jeff Davis
that initdb -D data --nosync sync only takes a couple seconds. Clearly batching the operation is a big help. Maybe there's some more efficient way to fsync a lot of files/directories? Or maybe I can mitigate it by avoiding files that don't really need to be fsync'd? Regards, Jeff Davis

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-22 Thread Jeff Davis
might want to include the prepared transaction's gid in the errdetail. I like this idea. 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

Re: [HACKERS] initdb and fsync

2012-02-05 Thread Jeff Davis
care about 0.3s? 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

Re: [HACKERS] initdb and fsync

2012-02-04 Thread Jeff Davis
there are only a few places, so I don't think clutter is really the problem with the simple patch at this point (unless there is a portability problem with just calling fsync). Regards, Jeff Davis initdb-fsync.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2012-01-29 Thread Jeff Davis
. Regards, Jeff Davis PS: the test was run on my workstation (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz) with work_mem=512MB, shared_buffers=512MB, and checkpoint_segments=32. The rest of the settings were default. range-gist-comments.patch.gz Description: GNU Zip compressed data \timing

Re: [HACKERS] initdb and fsync

2012-01-28 Thread Jeff Davis
observed once (though I could probably reproduce it if I tried). The symptom was a log message indicating that PG_VERSION was missing or corrupt on a system that was previously started and online (albeit briefly for a test). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] initdb and fsync

2012-01-28 Thread Jeff Davis
to be written out. 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

[HACKERS] initdb and fsync

2012-01-27 Thread Jeff Davis
-independent fsync be available at initdb time? 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

Re: [HACKERS] Page Checksums

2011-12-27 Thread Jeff Davis
for 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

Re: [HACKERS] Page Checksums

2011-12-27 Thread Jeff Davis
complicated we make the verification process, the less workable that becomes. I vote for a simple way to calculate the checksum -- fixed offsets of each page (of course, it would need to know the page size), and a standard checksum algorithm. Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] Page Checksums

2011-12-27 Thread Jeff Davis
like ZFS than ext3. They do all writes to a new location, thus fragmenting the files. That may be a good trade-off for some people, but it's not free. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Page Checksums

2011-12-27 Thread Jeff Davis
some weird i/o scheduling going on. That would also depend on how many disks you have and what configuration they're in, right? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Page Checksums + Double Writes

2011-12-27 Thread Jeff Davis
complete, we would catch many common types of corruption, and we'd be in a much better position to think clearly about hint bits, double writes, etc. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Page Checksums + Double Writes

2011-12-27 Thread Jeff Davis
On Tue, 2011-12-27 at 16:43 -0600, Merlin Moncure wrote: On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis pg...@j-davis.com wrote: 3. Attack hint bits problem. A large number of problems would go away if the current hint bit system could be replaced with something that did not require writing

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-12-21 Thread Jeff Davis
a while to work through the logic, but I would have been lost completely without the comments around the double sorting split. Regards, Jeff Davis *** a/src/backend/utils/adt/rangetypes_gist.c --- b/src/backend/utils/adt/rangetypes_gist.c *** *** 39,45 ((RangeType

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-12-21 Thread Jeff Davis
tackled the simple (and hopefully common) case when the ranges are about the same size. 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-12-12 Thread Jeff Davis
/set_range_contain_empty, but didn't use them. I think this was a merge error, but I removed them. So now there are no changes in rangetypes.c. Regards, Jeff Davis range_gist_cleanup.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Why so few built-in range types?

2011-11-30 Thread Jeff Davis
collation C, right? Do you think that would be useful to enough people? One that I'd like to see is an IP address type, but that's complicated because inet and cidr support netmasks. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] GiST range-contained-by searches versus empty ranges

2011-11-29 Thread Jeff Davis
for contains empty ranges. However, it still sounds like a useful improvement to me. 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-11-25 Thread Jeff Davis
, though I'm still working through the details. 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

Re: [HACKERS] Obstacles to user-defined range canonicalization functions

2011-11-24 Thread Jeff Davis
is based on numeric? 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

Re: [HACKERS] Singleton range constructors versus functional coercion notation

2011-11-22 Thread Jeff Davis
(x), as I picked earlier, and run into the same problems. It's a little strange that we allow people to define functions with one argument and the same name as a type if such functions are confusing. This isn't intended as an argument in either direction, just an observation. Regards, Jeff

Re: [HACKERS] Singleton range constructors versus functional coercion notation

2011-11-20 Thread Jeff Davis
points (both then and in a reply now). Also, Robert wasn't convinced that '[]' is necessarily better for discrete ranges: http://archives.postgresql.org/pgsql-hackers/2011-10/msg00598.php Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] range_adjacent and discrete ranges

2011-11-19 Thread Jeff Davis
of range_adjacent might mean that it's useful elsewhere, too, so now I'm leaning toward supporting [3,3) as an empty range. 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

Re: [HACKERS] Singleton range constructors versus functional coercion notation

2011-11-19 Thread Jeff Davis
is also very minor. 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

Re: [HACKERS] Are range_before and range_after commutator operators?

2011-11-18 Thread Jeff Davis
of the operators, and it was the best that I came up with. The nice thing about it is that it can compare a lower bound to another lower bound, or to an upper bound. Then again, perhaps I tried to hard to unify those concepts, and it just led to complexity? I'm open to suggestion. Regards, Jeff Davis

[HACKERS] range_adjacent and discrete ranges

2011-11-18 Thread Jeff Davis
, 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

Re: [HACKERS] range_adjacent and discrete ranges

2011-11-18 Thread Jeff Davis
to do with canonical functions? This seems more like a constructor issue, and there is already a zero-argument constructor to make empty ranges. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] range_adjacent and discrete ranges

2011-11-18 Thread Jeff Davis
On Fri, 2011-11-18 at 13:32 +0100, Florian Pflug wrote: That information, however, *is* already contained in the canonical functions, because those function know that (2,3) are empty as an integer range, but non-empty as a float range. Very good point. Thank you. Regards, Jeff Davis

Re: [HACKERS] Are range_before and range_after commutator operators?

2011-11-17 Thread Jeff Davis
, but it is escaping me now. What edge cases did you have in mind? Regards, Jeff Davis cmp-bounds-2017.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

Re: [HACKERS] declarations of range-vs-element @ and @

2011-11-17 Thread Jeff Davis
to me. 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

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-14 Thread Jeff Davis
sense to me. 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

Re: [HACKERS] Cause of intermittent rangetypes regression test failures

2011-11-13 Thread Jeff Davis
marking it VOLATILE. Thoughts, other ideas? 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

Re: [HACKERS] btree gist known problems

2011-11-07 Thread Jeff Davis
On Mon, 2011-11-07 at 10:18 -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: I'm looking for known problem areas in btree_gist. I see: http://archives.postgresql.org/message-id/8973.1286841...@sss.pgh.pa.us With Range Types, I'm anticipating that btree_gist will become more

[HACKERS] btree gist known problems

2011-11-06 Thread Jeff Davis
? Or does btree_gist just need a good review? Or have the problems been fixed? 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-11-04 Thread Jeff Davis
) function. That's fine with me. At best, they were only marginally useful. 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-11-04 Thread Jeff Davis
. The only change I found strange was the test that used \c to reconnect; but I can't say that my solution was any better. 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-11-04 Thread Jeff Davis
a very good answer, and even for the contains a point case I'll have to think about the representation in pg_statistic. 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

Re: [HACKERS]

2011-10-31 Thread Jeff Davis
parsing after the record parsing. 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

[HACKERS] strange code in array_in

2011-10-29 Thread Jeff Davis
simple? 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

Re: [HACKERS] strange code in array_in

2011-10-29 Thread Jeff Davis
, but at the time I was slightly confused by it. I guess I just haven't seen that idiom before. 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-26 Thread Jeff Davis
, 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-25 Thread Jeff Davis
-xid cache is potentially vulnerable to xid wraparound for the same reason. 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

Re: [HACKERS] (patch) regression diffs on collate.linux.utf8 test

2011-10-19 Thread Jeff Davis
On Wed, 2011-10-19 at 11:44 +0300, Peter Eisentraut wrote: On tis, 2011-10-18 at 21:47 -0700, Jeff Davis wrote: On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote: Presumably because Jeff doesn't have that particular locale installed. locale -a would clarify that. $ locale

Re: [HACKERS] (patch) regression diffs on collate.linux.utf8 test

2011-10-19 Thread Jeff Davis
On Wed, 2011-10-19 at 10:10 -0700, Jeff Davis wrote: dpkg-reconfigure locales I had to manually do # locale-gen tr_TR to make it generate tr_TR.ISO-8859-9, and now it works. I'm not sure what we should do, exactly, but I expect that others who attempt to run the test on ubuntu (and maybe

Re: [HACKERS] (patch) regression diffs on collate.linux.utf8 test

2011-10-18 Thread Jeff Davis
On Sun, 2011-10-16 at 16:00 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: On master, I see a minor test error (at least on my machine) as well as a diff. Patch attached. Hmm, yeah, I forgot to fix this regression test when I added that DETAIL line. However, I don't see

[HACKERS] new compiler warnings

2011-10-18 Thread Jeff Davis
:9: note: array 't_bits' declared here bits8 t_bits[1]; /* bitmap of NULLs -- VARIABLE LENGTH */ == Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] (patch) regression diffs on collate.linux.utf8 test

2011-10-18 Thread Jeff Davis
happen to know what package I need for just plain tr_TR? 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-10-17 Thread Jeff Davis
On Sun, 2011-10-16 at 14:43 -0700, Jeff Davis wrote: On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: The first thing caught my eye in existing GiST code is idea of subtype_float. float8 has limited precision and can't respresent, for example, varlena values good enough. Even

[HACKERS] (patch) regression diffs on collate.linux.utf8 test

2011-10-16 Thread Jeff Davis
On master, I see a minor test error (at least on my machine) as well as a diff. Patch attached. Regards, Jeff Davis *** a/src/test/regress/expected/collate.linux.utf8.out --- b/src/test/regress/expected/collate.linux.utf8.out *** *** 395,401 SELECT relname FROM pg_class

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-10-16 Thread Jeff Davis
let me know. Otherwise I'll just finish implementing subtype_diff. 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

Re: [HACKERS] COUNT(*) and index-only scans

2011-10-12 Thread Jeff Davis
value may diminish quite a bit before the next auto-analyze fires. I think if we can figure out what to do about that problem we'll be well on our way... Can you send stats messages to keep track when you unset a bit in the VM? That might allow it to be more up-to-date. Regards, Jeff

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-11 Thread Jeff Davis
'[]' as the default or having the default vary between types. So, the only real option remaining, if we do have a default, is '[)'. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-11 Thread Jeff Davis
included it, it could be confusing. We could go back to having different constructor names for different inclusivity; e.g. int4range_cc(1,10). That at least removes the awkwardness of typing (and seeing) '[]'. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-11 Thread Jeff Davis
by it. If you want a bigger range, use int8range or numrange -- the same advice we give to people who want unsigned types. Or, for people who really need the entire range of signed int4 exactly, they can easily make their own range type that canonicalizes to '[]'. Regards, Jeff Davis

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-10 Thread Jeff Davis
inclusivity) of the constructor. However, I removed the default_flags parameter because, as Florian pointed out, it's better to have a consistent output from the constructor. I'm open to suggestions, including potentially bringing back default_flags. Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-10 Thread Jeff Davis
still some slight awkwardness because int4range(1,10) would be '[1,9]'. 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-10 Thread Jeff Davis
). 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-10 Thread Jeff Davis
types are for continuous ranges like timestamps. And (as I pointed out in reply to Florian) there are good reasons to use the '[)' convention for those cases. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-10 Thread Jeff Davis
short of practical. Maybe a few extra characters at the end aren't so bad. I'd like to hear from some potential users though to see if anyone recoils at the common case. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-10-08 Thread Jeff Davis
. 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

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

2011-10-08 Thread Jeff Davis
, 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-08 Thread Jeff Davis
-farm? make check LANG=en_US does pass Thank you for pointing that out. I think I need to remove those before commit, but I just wanted them in there now to exercise that part of the code. Is there a better way to test collations like that? Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-06 Thread Jeff Davis
to consider unbounded and empty ranges specially. I made an attempt to do so in the current GiST code, and you might want to take a look at that first. I'm not particularly attached to my approach, but we should do something reasonable with unbounded and empty ranges. Regards, Jeff Davis

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-10-02 Thread Jeff Davis
reasonable to me. Unless someone objects, I'll make the change in the next patch. 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

Re: [HACKERS] Range Types - symmetric

2011-09-25 Thread Jeff Davis
don't see it as valuable enough to justify changing the grammar. Also, that still leaves confusion about inclusivity when applied to range types. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-22 Thread Jeff Davis
ranges I don't have a strong opinion. I'd be OK with any of those. 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

Re: [HACKERS] memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)

2011-09-22 Thread Jeff Davis
how big it is? 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

Re: [HACKERS] memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)

2011-09-22 Thread Jeff Davis
-num_items. Maybe that's the dependency that's not respected? 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-21 Thread Jeff Davis
/infinity confusion. 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-21 Thread Jeff Davis
wondering what happens if if you have a text range is (nubile, null) ambiguous?) There are a few ways to handle that. I would lean toward parsing the NULL as a special keyword, and then rejecting it (does it matter if it's upper case?). Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-21 Thread Jeff Davis
avoiding the infinity vs. NULL confusion. OK, I like that. Slightly strange to require quoting empty strings, but not stranger than the alternatives. While we're at it, any suggestions on the text representation of an empty range? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-21 Thread Jeff Davis
is never equal to a value in the data type's domain, so no, it's not the same. I think that we pretty much settled on just using an empty string for infinity in the other thread, right? So that makes this a non-issue. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-19 Thread Jeff Davis
, 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

Re: [HACKERS] Range Types - typo + NULL string constructor

2011-09-19 Thread Jeff Davis
(because they don't make sense for ranges -- in fact, avoiding the need to constantly special-case NULLs is one of the reasons to use range types). So, we want to avoid confusion where possible. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Range Types - symmetric

2011-09-13 Thread Jeff Davis
: '[5,2)'::int4range? Is that really '[2,5)' or '(2,5]'? 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

[HACKERS] collation, arrays, and ranges

2011-09-12 Thread Jeff Davis
by their internal collation, but don't take part in the logic that passes collation through the type system. Comments? 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] collation, arrays, and ranges

2011-09-10 Thread Jeff Davis
by their internal collation, but don't take part in the logic that passes collation through the type system. Comments? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] collation, arrays, and ranges

2011-09-10 Thread Jeff Davis
-- every caller of get_typcollation would need to be careful. 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

[HACKERS] casting between range types

2011-08-31 Thread Jeff Davis
sound like a cast to me at all. So, I'm leaning toward just not providing any casts from one range type to another. Thoughts? Regards Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] casting between range types

2011-08-31 Thread Jeff Davis
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote: On 31.08.2011 09:14, Jeff Davis wrote: First, a range is really a set. So if we take '[1,10)'::int4range and cast that to numrange, we end up moving from a set of exactly 9 elements to a set of an infinite number of elements

Re: [HACKERS] pg_restore --no-post-data and --post-data-only

2011-08-26 Thread Jeff Davis
On Fri, 2011-08-26 at 12:46 -0400, Robert Haas wrote: --sections='predata data' --sections='postdata' --sections='index' Agreed. After command line options reach a certain level of complexity, I think it's worth looking for a more general way to express them. Regards, Jeff Davis

[HACKERS] Range Types

2011-08-23 Thread Jeff Davis
://archives.postgresql.org/pgsql-hackers/2011-06/msg02046.php http://archives.postgresql.org/pgsql-hackers/2011-07/msg00210.php * Send/recv functions * cleanup * documentation updates Regards, Jeff Davis rangetypes-20110822.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing

Re: [HACKERS] skip WAL on COPY patch

2011-08-23 Thread Jeff Davis
then use that information for a number of optimizations that make sense for large loads. 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

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
. Agreed. Perhaps we need a new utility command to set the snapshot to make the error handling a little more obvious? 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

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
the session will remain in a transaction block. 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

Re: [HACKERS] synchronized snapshots

2011-08-16 Thread Jeff Davis
it? SET TRANSACTION SNAPSHOT perhaps? 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

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-08-12 Thread Jeff Davis
with me. 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

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-08-11 Thread Jeff Davis
to 9.0 and 9.1 docs, but leave it out of 'master'. That way it sticks around for a while but we don't have to remember to remove it later. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] augmenting MultiXacts to improve foreign keys

2011-08-09 Thread Jeff Davis
discussed. ] 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

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

2011-08-09 Thread Jeff Davis
), Tom seemed OK with it and Peter did not seem to like it much. I think I agree with Peter here that it's not a very good idea, and I don't see a big upside. With tablespaces it seems to make a little bit more sense, but I'd still lean away from that idea. Regards, Jeff Davis -- Sent

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

2011-08-09 Thread Jeff Davis
On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote: Attached is a patch against master which will cause a directory that contains only lost+found to still be treated as empty. Please add this to the September commitfest at: https://commitfest.postgresql.org/ Regards, Jeff Davis

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

2011-08-06 Thread Jeff Davis
still write to many tables that way, and that could mean many fsyncs. Also, there may be a bunch of other transactions trying to write to the WAL that have to wait as your transaction has to seek out to fsync the data file and then seek back to the WAL. Regards, Jeff Davis -- Sent via

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

2011-08-05 Thread Jeff Davis
case (where many checkpoints may happen during a single transaction anyway), it happens that avoiding WAL is a performance win, because the seeks are not the dominant cost. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] lazy vxid locks, v3

2011-08-04 Thread Jeff Davis
for committer. 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

Re: [HACKERS] Transient plans versus the SPI API

2011-08-04 Thread Jeff Davis
(which would require you to specify any parameters not bound yet). Maybe we don't need to expose all of those steps (although maybe we do), but it would be nice if the API we do offer resembles those steps. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Transient plans versus the SPI API

2011-08-04 Thread Jeff Davis
brought up some useful points along these lines. 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

Re: [HACKERS] Transient plans versus the SPI API

2011-08-04 Thread Jeff Davis
, 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

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

2011-08-04 Thread Jeff Davis
record all such page modifications so that they return to a consistent state. 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

<    1   2   3   4   5   6   7   8   9   10   >