[HACKERS] Avoiding io penalty when updating large objects

2005-06-28 Thread Mark Dilger
. It doesn't make sense to have a really wide table to represent the tree for multiple reasons, mostly involving data duplication in the leftward columns but also because you can't know ahead of time how wide to make the table. I look forward to any useful responses. Thanks, Mark Dilger

Re: [GENERAL] [HACKERS] Avoiding io penalty when updating large objects

2005-06-28 Thread Mark Dilger
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: On Tue, Jun 28, 2005 at 07:38:43PM -0700, Mark Dilger wrote: If, for a given row, the value of c is, say, approximately 2^30 bytes large, then I would expect it to be divided up into 8K chunks in an external table, and I should

[HACKERS] 64-bit API for large objects

2005-09-18 Thread Mark Dilger
My company has written a 64-bit large object API, extending the postgresql server to be able to read/write/seek/tell/open/close objects larger than 2GB. If the hackers community considers this valuable, we will submit the changes back for the rest of the community to share. From one of my

Re: [HACKERS] 64-bit API for large objects

2005-09-19 Thread Mark Dilger
Jonah H. Harris wrote: Mark, If you don't mind contributing the changes, we'd be glad to take a look at them. Thanks. -Jonah Ok, we will post it back soon. We have tested it on two different 64-bit architectures (Sparc and AMD) and are now testing on pentium before posting up to the

Re: [HACKERS] ROLLBACK triggers?

2006-01-25 Thread Mark Dilger
Daisuke Maki wrote: Hi, First, apologies if my question is a bit off-course. Please feel free to direct me to a different mailing list if not appropriate. I'm currently trying to embed Senna full text search engine (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by

Re: [HACKERS] Passing arguments to views

2006-02-03 Thread Mark Dilger
Tom Lane wrote: Chris Campbell [EMAIL PROTECTED] writes: True, as long as there's a hook to do the inlining/rewriting before the query's planned. I guess we can see function calls at the parse stage, check to see if they're SQL functions or not, grab the prosrc, do the substitution, then

Re: [HACKERS] Passing arguments to views

2006-02-03 Thread Mark Dilger
Josh Berkus wrote: Tom, As for the dependency issue, one man's bug is another man's feature. I think the fact that we don't track the internal dependencies of functions is not all bad. We've certainly seen plenty of complaints about how you can't easily change tables that a view is depending

Re: [HACKERS] Passing arguments to views

2006-02-03 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: If we are talking about inserting the function definition into the query as a subquery and then letting the parser treat it as a subquery, then I see no reason to use either the existing function or view subsystems. It sounds more like we

Re: [HACKERS] Function Stats WAS: Passing arguments to views

2006-02-03 Thread Mark Dilger
Josh Berkus wrote: Mark, This would only seem to work for trivial functions. Most functions that I write are themselves dependent on underlying tables, and without any idea how many rows are in the tables, and without any idea of the statistical distribution of those rows, I can't really say

Re: [HACKERS] Function Stats WAS: Passing arguments to views

2006-02-03 Thread Mark Dilger
Josh Berkus wrote: Tom, What I'd like to do is implement the constant method for 8.2, and work on doing the S() method later on. Does that make sense? I'm not thrilled with putting in a stopgap that we will have to support forever. The constant method is *clearly* inadequate for many

Re: [HACKERS] Function Stats WAS: Passing arguments to views

2006-02-03 Thread Mark Dilger
Mark Dilger wrote: I've been thinking about this more, and now I don't see why this is an issue. When the planner estimates how many rows will be returned from a subquery that is being used within a join, it can't know which parameters to use either. (Parameters being whatever conditions

[HACKERS] Getting the length of varlength data using PG_DETOAST_DATUM_SLICE or similar?

2006-02-10 Thread Mark Dilger
Hello, could anyone tell me, for a user contributed variable length data type, how can you access the length of the data without pulling the entire thing from disk? Is there a function or macro for this? As a first cut, I tried using the PG_DETOAST_DATUM_SLICE macro, but to no avail.

Re: [HACKERS] Getting the length of varlength data using PG_DETOAST_DATUM_SLICE

2006-02-10 Thread Mark Dilger
Bruce Momjian wrote: Have you looked at the 8.1.X buildin function pg_column_size()? Thanks Bruce for the lead. I didn't know what to grep for; this helps. The header comment for that function says Return the size of a datum, possibly compressed I take it the uncompressed length is

Re: [HACKERS] Getting the length of varlength data using PG_DETOAST_DATUM_SLICE

2006-02-11 Thread Mark Dilger
byteaoctetlen/textoctetlen calls toast_raw_datum_size. On Sat, 11 Feb 2006, Bruce Momjian wrote: Have you looked at the 8.1.X buildin function pg_column_size()? --- Mark Dilger wrote: Hello, could anyone tell me

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Milen A. Radev [EMAIL PROTECTED] writes: Milorad Poluga напи�а: SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval ?column? --- 3 mons -14 days Why not '2 mons 16 days' ? Please read the last paragraph in section

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Mark Dilger wrote: Tom Lane wrote: Milen A. Radev [EMAIL PROTECTED] writes: Milorad Poluga напи�а: SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15 days'::interval ?column?--- 3 mons -14 days Why not '2 mons 16 days' ? Please read the last

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I don't think we can accept a change that takes a negative and turns it into a positive and negative. Yeah, I find the patch's changes to the regression results pretty disturbing. Perhaps the correct definition ought to be like

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Hannu Krosing wrote: But unfortunately '2 mons -1 days' '1 mons 29 days' If I want something to happen 1 day less than two months from dome date, then the only way to say that consistently *is* '2 mons -1 days'. Correct me if I am wrong, but I thought that justify_days would only be called

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: I guess I would expect a good result to satisfy one of these three cases: * month 0 and 0 = day 30 * month 0 and -30 day = 0 * month = 0 and -30 day 30 If you believe that then 1 month -95

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: The current code (without the patch) behaves as follows: select justify_days(justify_hours('1 month 95 days -36:00:00'::interval)); justify_days - 4 mons 4 days -12:00:00 So? If we liked

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Bruce Momjian wrote: Mark Dilger wrote: Your proposal is that justify_hours borrows 24 hours from the days column in order to bring the -12 hours up to a positive 12 hours. Should it only do that if the days column is a positive number? What if it is negative? I think we all agree

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
A new patch is attached. Please note the regression differences. mark Index: src/backend/utils/adt/timestamp.c === RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v retrieving revision 1.160 diff --context=5

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Am I correct that the second case should still have negative hours? Yes... If so, then justify_hours(...) needs to examine the sign of the days and months portion of the interval while performing its work. No, it should ignore

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Bruce Momjian wrote: If we do that, we should just call it justify_interval(). I am thinking this is the direction to go, and for people who want more control they use the justify_hours and justify_days, and those are left unchanged. I agree. Let's leave the existing functions alone. I can

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Well, the question is whether justify_days has a sane definition that is different from this. Based on your example, I'm not seeing one. Backwards compatibility is probably more important than sanity. Let's just deprecate the existing functions and recommend that people use

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: This overall design seems more flexible than Tom's recent post in which he stated that justify_days should call justify_hours internally. AFAIR I said the exact opposite. regards, tom lane Tom Lane also wrote

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Bruce Momjian wrote: Even if we had people do: justify_hours(justify_days(justify_hours())) I don't think that would do what we want in all cases. Consider '1 mon -1 hour'. That should be '29 days 23 hours' but neither existing function, even if modified, will allow us to return

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: justify_days(justify_hours(...)) fixes *everything* in the most recently submitted patch, regardless of the convoluted case you invent. There is no data for which it won't work. If so, one function or the other is cheating. Per

Re: [HACKERS] [SQL] Interval subtracting

2006-03-01 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: If so, one function or the other is cheating. That depends what you mean by cheating. The justify_hours function looks to see what answer justify_days would give, but does not actually change the data. I described

Re: [HACKERS] PG Extensions: Must be statically linked?

2006-03-03 Thread Mark Dilger
Tom Lane wrote: My concern about how nicely libstdc++ will play in the backend environment still stands though. I have had the same concern, though never any hard evidence of a problem. If the C++ functions are wrapped with extern C, and all exceptions caught (perhaps converted into error

Re: [HACKERS] [SQL] Interval subtracting

2006-03-03 Thread Mark Dilger
Attached is the new patch. To summarize: - new function justify_interval(interval) - modified function justify_hours(interval) - modified function justify_days(interval) These functions are defined to meet the requirements as discussed in this thread. Specifically: - justify_hours

[HACKERS] not checking value returned from palloc?

2006-03-19 Thread Mark Dilger
Looking through the postgresql source code, I notice that there are many places were palloc is used but the return value is not checked to see if it is null. There are a few places such as: if (!PointerIsValid(result = palloc(CASH_BUFSZ + 2 - count + strlen(nsymbol

Re: [HACKERS] not checking value returned from palloc?

2006-03-19 Thread Mark Dilger
Peter Eisentraut wrote: Mark Dilger wrote: Looking through the postgresql source code, I notice that there are many places were palloc is used but the return value is not checked to see if it is null. palloc will throw an exception if it cannot fulfill the request. Code that checks

Re: [HACKERS] Shared memory

2006-03-28 Thread Mark Dilger
Thomas Hallgren wrote: Martijn, I tried a Socket approach. Using the new IO stuff that arrived with Java 1.4 (SocketChannel etc.), the performance is really good. Especially on Linux where an SMP machine show a 1 to 1.5 ratio between one process doing ping-pong between two threads and two

Re: [HACKERS] WAL Bypass for indexes

2006-04-03 Thread Mark Dilger
Jonah H. Harris wrote: As long as it's optional, I guess it's OK to let the administrator deal with recovery. Of course, in addition to no-fsync, we'll have another *possibly* dangerous option. BTW, I've seen no-fsync used far too many times because people think they're hardware is

Re: [HACKERS] two-argument aggregates and SQL 2003

2006-04-14 Thread Mark Dilger
Tom Lane wrote: I would really prefer to see CREATE AGGREGATE normalized to have a syntax comparable to CREATE FUNCTION (or DROP AGGREGATE for that matter): CREATE AGGREGATE aggname (typname [, ... ]) ...definition... but it's not clear how to get there without breaking backwards

Re: [HACKERS] Logging pg_autovacuum

2006-04-29 Thread Mark Dilger
Should we make the whole postgres logging system configurable, similar to log4j (or log4perl) rather than special-casing the autovacuum logs? Do we want to see options added piecemeal to the conf file such as autovacuum_messages=silent? mark ---(end of

Re: [HACKERS] Is a SERIAL column a black box, or not?

2006-04-30 Thread Mark Dilger
Tom Lane wrote: 1. A serial column is a black box that you're not supposed to muck with the innards of. This philosophy leads to the proposal that we disallow modifying the column default expression of a serial column, and will ultimately lead to thoughts like trying to hide the associated

Re: [HACKERS] Is a SERIAL column a black box, or not?

2006-04-30 Thread Mark Dilger
[EMAIL PROTECTED] wrote: On Sun, Apr 30, 2006 at 09:14:53AM -0700, Mark Dilger wrote: Tom Lane wrote: 1. A serial column is a black box that you're not supposed to muck with the innards of. This philosophy leads to the proposal that we disallow modifying the column default expression

Re: [HACKERS] BEGIN inside transaction should be an error

2006-05-10 Thread Mark Dilger
Martijn van Oosterhout wrote: On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote: Could we make BEGIN fail when we already are in a transaction? We could, but it'd probably break about as many apps as it fixed. I wonder whether php shouldn't be complaining about this, instead ---

Re: [HACKERS] psql feature thought

2006-05-16 Thread Mark Dilger
Joshua D. Drake wrote: Hello, I was dinking around wand came across something that may (or may not be useful). What if single line statements that were seperated by ; within psql were implicitly within a transaction? E.g; postgres=# select * from foo; update foo set bar = 'baz';

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

2006-05-16 Thread Mark Dilger
David Wheeler wrote: Hellow PostgreSQL hackers, Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL function? try=# CREATE OR REPLACE FUNCTION inc_by_two( try(#upfrom int, try(#upto int try(# ) RETURNS SETOF INT AS $$ try$# BEGIN try$# FOR i IN

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

2006-05-16 Thread Mark Dilger
Mark Dilger wrote: David Wheeler wrote: Hellow PostgreSQL hackers, Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL function? try=# CREATE OR REPLACE FUNCTION inc_by_two( try(#upfrom int, try(#upto int try(# ) RETURNS SETOF INT AS $$ try$# BEGIN try$# FOR i

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

2006-05-16 Thread Mark Dilger
David Wheeler wrote: On May 16, 2006, at 16:53, Mark Dilger wrote: Sorry, I meant to say that it should only be a no-op according to the language specification, as I understand it. The fact that it works suggests to me that the implementation of PL/pgsql has been modified (or broken

Re: [HACKERS] Foreign key column reference ordering and information_schema

2006-05-17 Thread Mark Dilger
Stephan Szabo wrote: On Wed, 17 May 2006, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: Per the report from Clark C Evans a while back and associated discussion, it seems like recent versions of the SQL spec changed the rules for foreign key column references such that the columns

[HACKERS] text_position worst case runtime

2006-05-18 Thread Mark Dilger
The function static int32 text_position(text *t1, text *t2, int matchnum) defined in src/backend/utils/adt/varlena.c uses repeated calls to strncmp (or pg_wchar_strncmp) to find the location of the pattern in the text. The worst case runtime for such an approach is O(n*m) where n and m are

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

2006-05-18 Thread Mark Dilger
Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: True, but there were clear benefits from doing so. Disallowing = assignment in plpgsql wouldn't buy anything, just break programs. But it's already disallowed in most places. No it isn't. The plpgsql scanner treats := and = as

Re: [HACKERS] PL/pgSQL 'i = i + 1' Syntax

2006-05-18 Thread Mark Dilger
Douglas McNaught wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: No it isn't. The plpgsql scanner treats := and = as *the same token*. They can be interchanged freely. This has nothing to do with the case of modifying a loop variable in particular. I disagree. If the scanner

Re: [HACKERS] text_position worst case runtime

2006-05-18 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: The function static int32 text_position(text *t1, text *t2, int matchnum) defined in src/backend/utils/adt/varlena.c uses repeated calls to strncmp (or pg_wchar_strncmp) to find the location of the pattern in the text. The worst case

Re: [HACKERS] text_position worst case runtime

2006-05-19 Thread Mark Dilger
Tom Lane wrote: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: And how much code would those take? The bottom line here is that we don't have a pile of complaints about the performance of text_position, so it's difficult to justify making it much more complicated than

Re: [HACKERS] String Similarity

2006-05-19 Thread Mark Dilger
Mark Woodward wrote: I have a side project that needs to intelligently know if two strings are contextually similar. Think about how CDDB information is collected and sorted. It isn't perfect, but there should be enough information to be usable. Think about this: pink floyd - dark side

Re: [HACKERS] An Idea for planner hints

2006-08-08 Thread Mark Dilger
If this feature I'm proposing already exists, sorry for the waste of bandwidth, and could someone please point me to it? :) What if there were a mode that told postgres to do an exhaustive search (or if not exhaustive, then much more extensive search) of all plans (or many plans), trying each

Re: [HACKERS] An Idea for planner hints

2006-08-08 Thread Mark Dilger
Tom Lane wrote: The thing I object to about the I want to decorate my queries with planner hints mindset is that it's coming at it from the wrong direction. You should never be thinking in terms of fix this one query, because that just leads back into the same dead end that your fix doesn't

Re: [HACKERS] An Idea for planner hints

2006-08-09 Thread Mark Dilger
it.) It would be *so much easier* to have an option to tell the planner to try them all. mark On Tue, Aug 08, 2006 at 08:23:05AM -0700, Mark Dilger wrote: If this feature I'm proposing already exists, sorry for the waste of bandwidth, and could someone please point me to it? :) What

Re: [HACKERS] An Idea for planner hints

2006-08-22 Thread Mark Dilger
Peter Eisentraut wrote: Jim C. Nasby wrote: Meet EXPLAIN ANALYZE. Which does no good for apps that you don't control the code on. Even if you do control the code, you have to find a way to stick EXPLAIN ANALYZE in front of every query, and figure out how to deal with what's comming back.

Re: [HACKERS] An Idea for planner hints

2006-08-23 Thread Mark Dilger
Jim C. Nasby wrote: On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote: I proposed something like this quite a bit up-thread. I was hoping we could have a mode in which the system would run the second, third, fourth, ... best plans rather than just the best looking one

Re: [HACKERS] An Idea for planner hints

2006-08-24 Thread Mark Dilger
Is there actually evidence that there's a lot of problems with bad join orders? ISTM that's one of the areas where the planner actually does a pretty good job. I put together a quick demonstration using AxBxC where AxB is empty but AxC is not. Sure enough, postgres chooses AxC first, then xB,

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread Mark Dilger
Tom Lane wrote: I can see various things that we might consider doing: 1. Just flip the names of the two operators added by the GIN patch. 2. #1 plus flip the names of the various contrib operators that are out of sync (Michael Fuhr points out that contrib/intarray is out of step too

Re: [HACKERS] Fixed length data types issue

2006-09-10 Thread Mark Dilger
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: No one has mentioned that we page value on disk to match the CPU alignment. This is done for efficiency, but is not strictly required. Well, it is unless you are willing to give up support of non-Intel CPUs; most other popular chips are

Re: [HACKERS] Fixed length data types issue

2006-09-10 Thread Mark Dilger
Martijn van Oosterhout wrote: On Sun, Sep 10, 2006 at 11:55:35AM -0700, Mark Dilger wrote: Well, it is unless you are willing to give up support of non-Intel CPUs; most other popular chips are strict about alignment, and will fail an attempt to do a nonaligned fetch. Intel CPUs are detectable

Re: [HACKERS] Fixed length data types issue

2006-09-10 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: ... The argument made upthread that a quadratic number of conversion operators is necessitated doesn't seem right to me, given that each type could upcast to the canonical built in type. (int1 = smallint, int3 = integer, ascii1 = text

Re: [HACKERS] Fixed length data types issue

2006-09-13 Thread Mark Dilger
Mark Dilger wrote: Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: ... The argument made upthread that a quadratic number of conversion operators is necessitated doesn't seem right to me, given that each type could upcast to the canonical built in type. (int1 = smallint, int3

Re: [HACKERS] Fixed length data types issue

2006-09-13 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: int1 works perfectly, as far as I can tell. int3 works great in memory, but can't be stored to a table. The problem seems to be that store_att_byval allows data of size 1 byte but not size 3 bytes, forcing me to pass int3 by reference

Re: [HACKERS] Fixed length data types issue

2006-09-13 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: Please provide a stack trace --- AFAIK there shouldn't be any reason why a pass-by-ref 3-byte type wouldn't work. (gdb) bt #0 0xb7e01d45 in memcpy () from /lib/libc.so.6 #1 0x08077ece in heap_fill_tuple (tupleDesc

Re: [HACKERS] Fixed length data types issue

2006-09-14 Thread Mark Dilger
My apologies if you are seeing this twice. I posted it last night, but it still does not appear to have made it to the group. Mark Dilger wrote: Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: Please provide a stack trace --- AFAIK there shouldn't be any reason why

Re: [HACKERS] Reducing data type space usage

2006-09-15 Thread Mark Dilger
Gregory Stark wrote: snip Case 2) Solving this is quite difficult without introducing major performance problems or security holes. The one approach we have that's practical right now is introducing special data types such as the oft-mentioned char data type. char doesn't have quite

Re: [HACKERS] Reducing data type space usage

2006-09-16 Thread Mark Dilger
Mark Dilger wrote: Wouldn't a 4-byte numeric be a float4 and an 8-byte numeric be a float8. I'm not sure I see the difference. Nevermind. I don't normally think about numeric as anything other than an arbitrarily large floating point type. But it does differ in that you can specify

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

2006-09-20 Thread Mark Dilger
Tom Lane wrote: Rereading what I just wrote, it might be as simple as allowing a two-step cast in certain cases, only if the first step is a domain to base type coercion (which we assume would be specially marked in pg_cast). But the devil is in the details ... and anyway there might be a

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

2006-09-20 Thread Mark Dilger
Mark Dilger wrote: Casts from int2 - int4, int2 - int8, and int4 - int8 would all be SAFE, I think, because they are not lossy. But perhaps I have not thought enough about this and these should be IMPLICIT rather than SAFE. I have thought about this some more. I think these are indeed SAFE

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

2006-09-20 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Mark Dilger wrote: Casts from int2 - int4, int2 - int8, and int4 - int8 would all be SAFE, I think, because they are not lossy. But perhaps I have not thought enough about this and these should be IMPLICIT rather than SAFE. I have

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

2006-09-20 Thread Mark Dilger
Tom Lane wrote: Now we do have the flexibility to alter the default contents of pg_cast --- there could be more or fewer entries in there than there are now, if the type coercion rules are altered to do less or more automatically than they do now. But the end-result behavior needs to wind up

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

2006-09-21 Thread Mark Dilger
Martijn van Oosterhout wrote: On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote: If the system chooses cast chains based on a breadth-first search, then the existing int2 - int8 cast would be chosen over an int2 - int4 - int8 chain, or an int2 - int3 - int4 - int8 chain, or in fact

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-03-31 Thread Mark Dilger
Bruce Momjian wrote: Added to TODO: * Fix cases where invalid byte encodings are accepted by the database, but throw an error on SELECT http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php Is anyone working on fixing this bug? Hi, has anyone

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-03-31 Thread Mark Dilger
Mark Dilger wrote: Bruce Momjian wrote: Added to TODO: * Fix cases where invalid byte encodings are accepted by the database, but throw an error on SELECT http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php Is anyone working on fixing this bug? Hi, has

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-01 Thread Mark Dilger
Martijn van Oosterhout wrote: There's also the performance angle. The current mbverify is very inefficient for encodings like UTF-8. You might need to refactor a bit there... There appears to be a lot of function call overhead in the current implementation. In pg_verify_mbstr, the function

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Andrew - Supernews wrote: On 2007-04-01, Mark Dilger [EMAIL PROTECTED] wrote: Do any of the string functions (see http://www.postgresql.org/docs/8.2/interactive/functions-string.html) run the risk of generating invalid utf8 encoded strings? Do I need to add checks? Are there known bugs

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Mark Dilger wrote: Andrew - Supernews wrote: On 2007-04-01, Mark Dilger [EMAIL PROTECTED] wrote: Do any of the string functions (see http://www.postgresql.org/docs/8.2/interactive/functions-string.html) run the risk of generating invalid utf8 encoded strings? Do I need to add checks

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: pgsql=# select chr(14989485); chr - 中 (1 row) Is there a principled rationale for this particular behavior as opposed to any other? In particular, in UTF8 land I'd have expected the argument of chr() to be interpreted as a Unicode

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Mark Dilger wrote: Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: pgsql=# select chr(14989485); chr - 中 (1 row) Is there a principled rationale for this particular behavior as opposed to any other? In particular, in UTF8 land I'd have expected the argument of chr

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Mark Dilger wrote: Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: pgsql=# select chr(14989485); chr - 中 (1 row) Is there a principled rationale for this particular behavior as opposed to any other? In particular, in UTF8 land I'd have expected the argument of chr

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-02 Thread Mark Dilger
Mark Dilger wrote: Since chr() is defined in oracle_compat.c, I decided to look at what Oracle might do. See http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/functions18a.htm It looks to me like they are doing the same thing that I did, though I don't have Oracle

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-03 Thread Mark Dilger
Martijn van Oosterhout wrote: On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote: IMHO this is the only good and intuitive way for CHR() and ASCII(). Hardly. The comment earlier about mbtowc was much closer to the mark. And wide characters are defined as Unicode points. Basically,

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-03 Thread Mark Dilger
Albe Laurenz wrote: What I suggest (and what Oracle implements, and isn't CHR() and ASCII() partly for Oracle compatibility?) is that CHR() and ASCII() convert between a character (in database encoding) and that database encoding in numeric form. Looking at Oracle documentation, it appears

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-04 Thread Mark Dilger
Albe Laurenz wrote: There's one thing that strikes me as weird in your implementation: pgsql=# select chr(0); ERROR: character 0x00 of encoding SQL_ASCII has no equivalent in UTF8 0x00 is a valid UNICODE code point and also a valid UTF-8 character! It's not my code that rejects this. I'm

Re: [HACKERS] Bug in UTF8-Validation Code?

2007-04-04 Thread Mark Dilger
Tatsuo Ishii wrote: SNIP. I think we need to continute design discussion, probably targetting for 8.4, not 8.3. The discussion came about because Andrew - Supernews noticed that chr() returns invalid utf8, and we're trying to fix all the bugs with invalid utf8 in the system. Something

[HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Mark Dilger
The \COPY command rejects multibyte delimiters. Is this intentional behavior? Here is an example of the behavior: [EMAIL PROTECTED] ~ $ touch foo [EMAIL PROTECTED] ~ $ psql -p Welcome to psql 8.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Mark Dilger
Andrew Dunstan wrote: Mark Dilger wrote: The \COPY command rejects multibyte delimiters. Is this intentional behavior? It is certainly a known limitation, and I suspect removing it could add non-trivial overhead to the input processing. What is the use case for using such a delimiter

Re: [HACKERS] plperl/plperlu interaction

2006-11-09 Thread Mark Dilger
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Anyway, it is probably not expected by many users that loading a module in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and plperl subtleties. I

Re: [HACKERS] Function execution costs 'n all that

2007-01-28 Thread Mark Dilger
Tom Lane wrote: Would a simple constant value be workable, or do we need some more complex model (and if so what)? Consider: ANALYZE myfunc(integer) ON (SELECT myfunc(7)) WITH RATIO 0.03; ANALYZE myfunc(text,text) ON (SELECT myfunc(mt.a,mt.b) FROM mytable mt) WITH RATIO 1.071; ANALYZE

Re: [HACKERS] Function execution costs 'n all that

2007-01-28 Thread Mark Dilger
Tom Lane wrote: Mark Dilger [EMAIL PROTECTED] writes: Tom Lane wrote: Would a simple constant value be workable, or do we need some more complex model (and if so what)? Consider: ANALYZE myfunc(integer) ON (SELECT myfunc(7)) WITH RATIO 0.03; ... It seems to me that the above system would

[HACKERS] Performance patch for Win32

2012-05-29 Thread Mark Dilger
This is a patch against src/backend/storage/file/fd.c taken from 9.2beta1. This patch is submitted for review and comments, not for application to the code base.  *WIP* This patch addresses a performance problem stemming from the use of FindFirstFile() and FindNextFile() to iterate over a

Re: [HACKERS] Performance patch for Win32

2012-05-29 Thread Mark Dilger
specific?  Clearly we could also take a Suffix argument, but if we go too far down this road we just reinvent regular expressions mark From: Tom Lane t...@sss.pgh.pa.us To: Mark Dilger markdil...@yahoo.com Cc: pgsql-hackers@postgresql.org pgsql-hackers

Re: [HACKERS] Performance patch for Win32

2012-05-29 Thread Mark Dilger
. From: Tom Lane t...@sss.pgh.pa.us To: Mark Dilger markdil...@yahoo.com Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org Sent: Tuesday, May 29, 2012 3:42 PM Subject: Re: [HACKERS] Performance patch for Win32 Mark Dilger markdil...@yahoo.com writes: I am hesitant to write

[HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

2013-12-30 Thread Mark Dilger
.  But the code is certainly easier to understand if the macro matches the definition of the struct. Mark Dilger fix_PGSTAT_NUM_TABENTRIES_macro Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

2013-12-31 Thread Mark Dilger
is needed, I might jump in. Mark Dilger On Tuesday, December 31, 2013 9:21 AM, Tom Lane t...@sss.pgh.pa.us wrote: Mark Dilger markdil...@yahoo.com writes: In src/include/pgstat.h, the PGSTAT_NUM_TABENTRIES macro attempts to subtract off the size of the PgStat_MsgTabstat struct up

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

2013-12-31 Thread Mark Dilger
for the compiler to detect if you change the struct but not the macro. I see these as similar to what I was talking about in src/include/pgstat.h. Mark Dilger src/include/pg_attribute.h: -- #define ATTRIBUTE_FIXED_PART_SIZE \     (offsetof(FormData_pg_attribute,attcollation

[HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

2013-12-31 Thread Mark Dilger
connect to the server with the partition you want to change. Thanks in advance for having even read this far Mark Dilger

Re: [HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

2013-12-31 Thread Mark Dilger
of the implementation so far, which will be resolved in the future? On Tuesday, December 31, 2013 12:33 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Mark Dilger wrote: This is not entirely pie in the sky, but feel free to tell me why this is crazy. Have you seen http://wiki.postgresql.org/wiki/BDR

Re: [HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

2014-01-02 Thread Mark Dilger
. mark On Thursday, January 2, 2014 1:19 AM, Andres Freund and...@2ndquadrant.com wrote: On 2013-12-31 13:51:08 -0800, Mark Dilger wrote: The BDR documentation http://wiki.postgresql.org/images/7/75/BDR_Presentation_PGCon2012.pdf says,     Physical replication forces us to use just one

Re: [HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

2014-01-02 Thread Mark Dilger
of people who would use this feature are probably the sort of people who would not mind hearing about it early. mark On Thursday, January 2, 2014 11:18 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-01-02 10:18:52 -0800, Mark Dilger wrote: I anticipated that my proposal would require

  1   2   3   >