Re: [mail] Re: [HACKERS] Windows Build System

2003-01-29 Thread Ron Mayer
Cool irony in the automated .sig on the mailinglist software... On Wed, 29 Jan 2003, Vince Vielhaber wrote: ... hammering the betas is a far cry from an industrial-strength solution. ... TIP 4: Don't 'kill -9' the postmaster Sounds like you're basically saying is _do_ 'kill -9' the

Re: [mail] Re: [HACKERS] Windows Build System

2003-01-30 Thread Ron Mayer
On Thu, 30 Jan 2003, Dave Page wrote: On Wed, 29 Jan 2003, Ron Mayer wrote: Cool irony in the automated .sig on the mailinglist software... [...] Sounds like you're basically saying is _do_ 'kill -9' the postmaster... and make sure it recovers gracefully... ... It's

Re: [HACKERS] PostgreSQL Tuning Results

2003-02-12 Thread Ron Mayer
Christopher Kings-Lynne wrote: I reckon that sort_mem is the hardest thing to optimise1 Agreed... in part because it depends a lot on the query. Also, if I understand correctly sort_mem not only affects sorts but also hash table stuff as well, right? If that's true for the new hash

Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Ron Mayer
Christopher Kings-Lynne wrote: *sigh* It's just like a standard to come up with a totally new syntax for a feature that no-one has except MySQL who use a different syntax :) You sure? :) http://otn.oracle.com/products/oracle9i/daily/Aug24.html MERGE INTO SALES_FACT D USING SALES_JUL01

Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Ron Mayer
FWIW, that's the approach O*'s taking. http://otn.oracle.com/products/oracle9i/daily/Aug24.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Eisentraut Sent: Tuesday, February 18, 2003 11:02 AM To: Christopher Kings-Lynne Cc: Tom Lane; Hackers

Re: [HACKERS] Case insensitivity, and option?

2003-03-12 Thread Ron Mayer
mlw wrote: ... select * from table where field = 'blah'; gave the same results as: select * from table where field = 'BLah'; I was shocked. (a) because I know a lot of my code could be easier to write ... select * from table where field ILIKE 'blAH'; -- ;-) is almost as easy :-) PS: no,

Re: [HACKERS] Autovacuum loose ends

2005-07-16 Thread Ron Mayer
Tom Lane wrote: ISTM the point of the delay parameters for autovac is to put a lid on its impact on interactive response. Seen in that light, you do not care exactly which table it's hitting at the moment. Unless the table in question takes a big lock when it's VACUUMed like tables with GiST

Re: [HACKERS] Imprecision of DAYS_PER_MONTH

2005-07-21 Thread Ron Mayer
Bruno Wolff III wrote: Shouldn't you be using 365.2425/12 (30.436875) for the number of days per month? Well, ISO 8601 prefers 30 to some weird fraction when they define the term month; and uses a different term calendar month for the exact number of days in a known month. They make a

Re: [HACKERS] A Guide to Constraint Exclusion (Partitioning)

2005-07-24 Thread Ron Mayer
Simon Riggs wrote: in those cases you are really just maintaining the indexes for partitioning purposes. On older data it may be desirable not to have lots of indexes, or at least use their resources on the indexes they really do want. Also, if you have a List partitioned table where all rows

Re: [HACKERS] US Census database (Tiger 2004FE) - 4.4G

2005-08-04 Thread Ron Mayer
Mark Woodward wrote: It is 4.4G in space in a gzip package. I'll mail a DVD to two people who promise to host it for Hackers. Would it be easier to release the program you did to do this conversion? I use this pretty short (274 line) C program: http://www.forensiclogic.com/tmp/tgr2sql.c

Re: [HACKERS] TODO questions

2005-08-24 Thread Ron Mayer
Joshua D. Drake wrote: ...when you comment something out, it should restore ...the contrary position is that a comment is a comment... ...If I comment out a parameter I expect... The most unambiguous behavior would be to not have commented out values in the config file at all. If someone

Re: [HACKERS] Call for 7.5 feature completion

2005-08-26 Thread Ron Mayer
Alvaro Herrera wrote: Or, slightly different, what are people's most wanted features? Things I would have found useful in the past year or so include: Standards stuff: * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) * The elementary OLAP stuff Contrib related

Re: [HACKERS] Call for 7.5 feature completion

2005-08-29 Thread Ron Mayer
Harald Fuchs wrote: In article [EMAIL PROTECTED], Christopher Kings-Lynne [EMAIL PROTECTED] writes: Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. Why? Perhaps Christopher meant select row_number() OVER (...) as rowid

Re: [HACKERS] On Logging

2005-09-26 Thread Ron Mayer
David Fetter wrote: ...log file formats in 8.0 * CSV * YAML * XML * Piped logs, as Apache can do * DB handle. I know this one will be controversial. [...] 1. Am I the only one who would wants an option for machine-readable logs? I'd very much like a format that can be easily loaded into

Re: [HACKERS] Supporting NULL elements in arrays

2005-11-09 Thread Ron Mayer
Joe Conway wrote: Last time I thought about this problem, that's what I concluded. I don't think there is a reasonable and backward compatible solution. I also think the best non-compatible solution is to require non-numeric elements to be delimited (double quotes, configurable?), and use

Re: [HACKERS] Top-k optimizations?

2005-01-13 Thread Ron Mayer
David Fetter wrote: Folks, As this came up in a work situation, I was wondering a little bit about the top-k issue. Right now, top-k is implemented (most easily, I think) via a SELECT with a LIMIT and no OFFSET. 3 questions arise from this. I think the simplest LIMIT query doesn't make it easy

Re: [HACKERS] Much Ado About COUNT(*)

2005-01-23 Thread Ron Mayer
Bruce Momjian wrote: Added to TODO based on this discusion:... * Speed up COUNT(*) One think I think would help lots of people is if the documentation near the COUNT aggregate explained some of the techniques using triggers to maintain a count for tables where this is important. For every one

Re: [HACKERS] Patent issues and 8.1

2005-02-01 Thread Ron Mayer
A new organization called the Software Freedom Law Center was announced yesterday; that seems like it may be one of the best places open-source groups could go for questions like this ARC pending patent. Eben Moglen (The FSF's main lawyer and Columbia Law prof), Diane Peters (OSDL's general

Re: [HACKERS] Query optimizer 8.0.1 (and 8.0)

2005-02-06 Thread Ron Mayer
Short summary: I had the same problem - since the sort order of zip-codes, counties, city names, and states don't match, the optimizer grossly overestimated the number of pages that would be read. I bet doing a CLUSTER by ZIP would solve that particular query, but would break similar queries

[HACKERS] correlation in pg_stats

2005-02-08 Thread Ron Mayer
Short summary: * It looks to me like the planner vastly overestimates the # of pages read by index scan in quite a few of my tables even though stats collected by ANALYZE are correct. * The problem happens any time you have multiple columns that have a number of repeated values

Re: [HACKERS] Query optimizer 8.0.1 (and 8.0)

2005-02-08 Thread Ron Mayer
[EMAIL PROTECTED] wrote: In this case, the behavior observed could be changed by altering the sample size for a table. I submit that an arbitrary fixed sample size is not a good base for the analyzer, but that the sample size should be based on the size of the table or some calculation of its

Re: [HACKERS] Query optimizer 8.0.1 (and 8.0)

2005-02-14 Thread Ron Mayer
[EMAIL PROTECTED] wrote: You know, I don't think a lot of people get the issues I was describing, or maybe they don't believe it, I don't know, but, I think that it would be a useful contrib project to create an 'analyze_special('table', 'column', 'method')' function that does a better job at

Re: [HACKERS] [pgsql-advocacy] Increased company involvement

2005-05-02 Thread Ron Mayer
Marc G. Fournier wrote: That is what pgFoundry was setup for ... to give projects the visibiilty they would get through the core distribution by making sure they are referenced in a central place, but providing the maintainers with direct CVS access to make changes to their code in a timely

Re: [HACKERS] soundex and metaphone

2005-05-27 Thread Ron Mayer
Jonah H. Harris wrote: I'm willing to move soundex and metaphone into the backend. Does anyone see a reason not to do so? As a kinda strange reason, I like them in contrib because they demonstrate a nice simple example of how one can write a contrib extension. This module has simple functions

Re: [HACKERS] The Contrib Roundup (long)

2005-06-08 Thread Ron Mayer
Josh Berkus wrote: intagg: what does this module do which is not already available through the built-in array functions and operators? Maybe I don't understand what it does. Unnatributed in the README. Move to pgfoundry? Short summary: Is there an equivalent of int_array_enum() built in?

Re: [HACKERS] The Contrib Roundup (long)

2005-06-08 Thread Ron Mayer
elein wrote: intarray: data_types/ what does this do that arrays do not? It provides lossy indexes that work well on big arrays; as well as some quite useful convenience functions that work on arrays of ints. ---(end of broadcast)--- TIP 7:

Re: [HACKERS] Checkpointing problem with new buffer mgr.

2005-06-19 Thread Ron Mayer
Tom Lane wrote: Hm, notice that the processor utilization doesn't actually drop all that much, so it seems it's not fundamentally an I/O storm kind of issue. If I read the chart on the bottom of Josh's links correctly, it looks to me like the fast one is spending 50% CPU in user and 30% CPU

Re: [HACKERS] Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking

2005-12-08 Thread Ron Mayer
Simon Riggs wrote: ...REINDEX...CREATE/DROP INDEX... I'm curious if partitioning can help help provide online create/reindex. For example, if I could set set up a table partitioned by modified time; could I make a new partition so all new inserts go into a new partition and then I can

Re: [HACKERS] ISO 8601 Intervals

2006-01-09 Thread Ron Mayer
Larry Rosenman wrote: Michael Glaesemann wrote: On Jan 8, 2006, at 12:12 , Larry Rosenman wrote: I was thinking of handling the TODO for ISO8601 Interval output. Just to be clear, you're talking about the ISO8601 duration syntax (PnYnMnDTnHnMnS), correct? (The SQL standard made the

Re: [HACKERS] ISO 8601 Intervals

2006-01-09 Thread Ron Mayer
://archives.postgresql.org/pgsql-patches/2003-12/msg00030.php on Peter Eisentraut's recommendation to implement SQL standard intervals first. Ron Mayer wrote: Larry Rosenman wrote: Michael Glaesemann wrote: On Jan 8, 2006, at 12:12 , Larry Rosenman wrote: I was thinking of handling the TODO

Re: [HACKERS] Automatic free space map filling

2006-03-04 Thread Ron Mayer
Jim C. Nasby wrote: ... how many pages per bit ... Are we trying to set up a complex solution to a problem that'll be mostly moot once partitioning is easier and partitioned tables are common? In many cases I can think of the bulk of the data would be in old partitions that are practically

Re: [HACKERS] Compression and on-disk sorting

2006-05-15 Thread Ron Mayer
Jim C. Nasby wrote: There's an fadvise that tells the OS to compress the data if it actually makes it to disk? Compressed-filesystem extension (like e2compr, and I think either Fat or NTFS) can do that. I think the reasons against adding this feature to postgresql are largely the same as the

Re: [HACKERS] optimizer cost calculation problem

2003-03-31 Thread Ron Mayer
Tom wrote: I find it really really hard to believe that it's wise to run with sort_mem exceeding 2 gig ;-). Does that installation have so much RAM that it can afford to run multiple many-Gb sorts concurrently? I don't do 2 gig... but I found 0.3 gig helped on a not-too-large system. In a

Re: [HACKERS] Pre-allocation of shared memory ...

2003-06-12 Thread Ron Mayer
Jeroen T. Vermeulen wrote: After that, where do you go? Try to find a reasonable process to shoot in the head. From what I heard, although I haven't kept current, a lot of work went into selecting a reasonable process, so there will be some determinism. FWIW, you can browse the logic linux

Re: [HACKERS] Two weeks to feature freeze

2003-06-19 Thread Ron Mayer
Tom wrote: Do we have any killer features added to 7.4 that we can shout about? We have a lot of pretty good stuff. You're not happy that the performance of IN (subselect) has been fixed? That btree index bloat is fixed... For warehousing reporting, Add hash for evaluating GROUP BY

Re: [HACKERS] [PATCHES] ISO 8601 Time Intervals of the format with time-unit designators

2003-09-08 Thread Ron Mayer
Tom wrote... At this point it should move to pghackers, I think. Background for pghackers first, open issues below... Over on pgpatches we've been discussing ISO syntax for “time intervals” of the “format with time-unit designators”.

[HACKERS] Broken(?) 'interval' problems. [Was: ISO 8601 Time Intervals]

2003-09-10 Thread Ron Mayer
Tom wrote: At this point it should move to pghackers, I think. (responding to a patch for ISO 8601 Time Intervals in pgsql-patches) Looks like I'll take a shot at more broadly hacking the postgresql time interval code. Before doing so, I wanted to ask opinions regarding what the right

Re: [HACKERS] Broken(?) 'interval' problems. [Was: ISO 8601 Time Intervals]

2003-09-10 Thread Ron Mayer
Bruno wrote: Can you document which part of a mixed interval (with both months and seconds parts) gets added first to a timestamp? I haven't ever run across anything which says which gets done first. In the existing code, the sql spec, or the proposed implementation? In the existing code,

Re: [HACKERS] Broken(?) 'interval' problems. [Was: ISO 8601 Time Intervals]

2003-09-10 Thread Ron Mayer
Bruno wrote: ...An interval has two parts... the number of months...and...the number of seconds...if both parts are nonzero it makes a difference in which part gets added first. For example '2003-02-28'::date + '1 month 1 day'::interval might be either 2003-03-29 or 2003-04-01. In 7.4 it is

Re: [HACKERS] More thoughts about planner's cost estimates

2006-06-06 Thread Ron Mayer
Tom Lane wrote: One objection to this is that after moving off the gold standard of 1.0 = one page fetch, there is no longer any clear meaning to the cost estimate units; you're faced with the fact that they're just an arbitrary scale. I'm not sure that's such a bad thing, though. It seems

[HACKERS] Running a query twice to ensure cached results.

2006-06-08 Thread Ron Mayer
Tom Lane wrote: -- do it again to ensure fully cached bench=# select count(*) from accounts; Short summary: Does running a query only twice really insure that a result is cached? It seems not to be the case for seq-scans on Linux. I think this may matters to the discussions about a

Re: [HACKERS] plPHP and plRuby

2006-07-19 Thread Ron Mayer
Peter Eisentraut wrote: Hannu Krosing wrote: So we would have src/pl/pljava/README.TXT and anybody looking for pl-s would find the info in a logical place Right. When was the last time any user looked under src/pl in the first place? Or even under src? If you're looking for pljava, it's

Re: [HACKERS] plPHP and plRuby

2006-07-19 Thread Ron Mayer
Tom Lane wrote: The difference is that I will have reasonable confidence that the README.TXT under src/pl will give instructions that match the version of PostgreSQL that I have. I assume that README will call out the version of PL/R or PL/Ruby that I want that was tested with the release of

Re: [HACKERS] Units in postgresql.conf

2006-07-20 Thread Ron Mayer
Peter Eisentraut wrote: I think it would be useful to allow units to be added to these settings, for example... shared_buffers = 512MB which is a bit cumbersome to calculate right now (you'd need = 65536). I haven't thought yet how to parse or implement this, but would people find this

Re: [HACKERS] On-disk bitmap index patch

2006-07-25 Thread Ron Mayer
Tom Lane wrote: [EMAIL PROTECTED] writes: Reading 1/4, for a larger table, has a good chance of being faster than reading 4/4 of the table. :-) Really? If you have to hit one tuple out of four, it's pretty much guaranteed that you will need to fetch every heap page. I think it's not

Re: [HACKERS] GUC with units, details

2006-07-27 Thread Ron Mayer
Peter Eisentraut wrote: Jim Nasby wrote: The truth is, virtually no one, even highly technical people, ever picks nits between kB vs KiB vs KB. The question isn't so much whether to allow KiB and such -- that would obviously be trivial. The question is whether we want to have kB mean 1000

Re: [HACKERS] On-disk bitmap index patch

2006-08-02 Thread Ron Mayer
Tom Lane wrote: Both of these pages say up front that they are considering read-only data. Can I assume read-mostly partitions could use the read-I/O efficient indexes on update-intensive partitions of the same table could use b-tree indexes? All of my larger (90GB+) tables can have

Re: [HACKERS] O_NOATIME

2006-08-03 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Would people be interested in a trivial patch that adds O_NOATIME to open() for platforms that support it? (apparently Linux 2.6.8 and better). Isn't that usually, and more portably, handled in the filesystem mount options? Yes to both

Re: [HACKERS] O_NOATIME

2006-08-03 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Tom Lane wrote: Isn't that usually, and more portably, handled in the filesystem mount options? Yes to both. I could imagine that for small systems/workstations you might have some files that want access time, and others that wanted

Re: [HACKERS] 8.2 features status

2006-08-05 Thread Ron Mayer
Tom Lane wrote: But a quick troll through the CVS logs shows ... multi-row VALUES, not only for INSERT but everywhere SELECT is allowed ... multi-argument aggregates, including SQL2003-standard statistical aggregates ... standard_conforming_strings can be turned on (HUGE deal for some people)

Re: [HACKERS] 8.2 features status

2006-08-05 Thread Ron Mayer
Tom Lane wrote: I tend to agree --- I don't see much value in trying to institute a formalized process. One more problem with the formalized process of claiming features in advance may stop what I suspect is a significant source of contributions -- people who add features/patches for internal

Re: [HACKERS] 8.2 features status

2006-08-05 Thread Ron Mayer
[EMAIL PROTECTED] wrote: Ron Mayer wrote: We have not had that many cases where lack of communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been

Re: [HACKERS] Optimizer improvements: to do or not to do?

2006-09-13 Thread Ron Mayer
Simon Riggs wrote: On Mon, 2006-09-11 at 06:20 -0700, Say42 wrote: That's what I want to do: 1. Replace not very useful indexCorrelation with indexClustering. An opinion such as not very useful isn't considered sufficient explanation or justification for a change around here. Not

Re: [HACKERS] Optimizer improvements: to do or not to do?

2006-09-13 Thread Ron Mayer
Gregory Stark wrote: Ron Mayer [EMAIL PROTECTED] writes: ...vastly overestimate the number of pages .. because postgresql's guess at the correlation being practically 0 despite the fact that the distinct values for any given column are closely packed on a few pages. I think we need

Re: [HACKERS] Fwd: Is the fsync() fake on FreeBSD6.1?

2006-09-24 Thread Ron Mayer
Andrew - Supernews wrote: Whether the underlying device lies about the write completion is another matter. All current SCSI disks have WCE enabled by default, which means that they will lie about write completion if FUA was not set in the request, which FreeBSD never sets. (It's not possible

Re: [HACKERS] [PATCH] Cleanup of GUC units code

2008-09-08 Thread Ron Mayer
Marko Kreen wrote: Thirdly, please don't use standard units argument, unless you plan to propose use of KiB, MiB, GiB at the same moment. In defense of standard units, if the postgres docs say Postgres will round up to the nearest power of 2 kB and MB seem very clear to me. If we want to

Re: [HACKERS] [PATCH] Cleanup of GUC units code

2008-09-10 Thread Ron Mayer
Robert Haas wrote: bits...bytes...blocks...m...M I can't imagine that taking away the B is somehow going to be more clear. If clarity is the goal, I'd want the following: a) Verbosely spelling out the units in the default config file temp_buffers = 16 megabytes or temp_buffers = 16

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-11 Thread Ron Mayer
Tom Lane wrote: Kevin Grittner [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] wrote: I am not sure about some of the corner cases --- anyone want to see if their understanding of the spec for interval string is different? The patch seems to support extensions to the standard. Right.

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-11 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Back a while ago (2003) there was some talk about replacing some of the non-standard extensions with shorthand forms of intervals with ISO 8601 intervals that have a similar but not-the-same shorthand. I think *replacement* would be a hard

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-11 Thread Ron Mayer
Tom Lane wrote: The other problem is that the SQL spec clearly defines an interval literal syntax, and it's not this ISO thing. So even without backward compatibility issues, 8601-only doesn't seem like it would fly. Oh. I wasn't proposing 8601-only. Just the one-character shorthands like

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-11 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: '1Y1M'::interval ... minute ... month Hmmm. I would say that the problem with that is not that it's nonstandard but that it's ambiguous. Ah yes. Our documentation...says...or abbreviations. ...What if we just tweak the code to reject

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-12 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: ... ISO 8601 intervals ... On the output side, seems like a GUC variable is the standard precedent here. I'd still vote against overloading DateStyle --- it does too much already --- but a separate variable for interval style wouldn't

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-12 Thread Ron Mayer
Tom Lane wrote: somewhat SQL-compliant on interval input, a GUC that selected PG traditional, SQL-standard, or ISO 8601 interval output format seems like it could be a good idea. Trying to do the SQL-standard output now, and have a question of what to do in the SQL-standard mode when trying to

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-12 Thread Ron Mayer
Tom Lane wrote: The reason it's not SQL-standard is the data value isn't. So not a problem. Someone conforming to the spec limits on what he puts in will see spec-compliant output. I think all you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if zeroes, omit dd if zero, omit hh:mm:ss if

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-12 Thread Ron Mayer
Ron Mayer wrote: Tom Lane wrote: you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe only if dd is also 0? otherwise your output is just dd which is uncomfortably ambiguous). Oh, and if both parts are 0, I guess we desire

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-12 Thread Ron Mayer
Tom Lane wrote: I think all you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe only if dd is also 0? otherwise your output is just dd which is uncomfortably ambiguous). Cool. I think I have it pretty much working with a new

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-13 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: interval ... sql_standard...iso_8601... backward_compatible ...depends... on ... DateStyle... ...How about decoupling interval_out's behavior from DateStyle altogether, and instead providing values of IntervalStyle that match all

[HACKERS] 8.3 vs HEAD difference in Interval output?

2008-09-15 Thread Ron Mayer
Unless I'm compiling stuff wrong, it seems HEAD is giving me slightly different output on Intervals than 8.3 in the roundoff of seconds. 8.3 was rounding to the nearest fraction of a second, HEAD seems to be truncating. In the psql output below it shows 8.3.1 outputting 6.70 secs while the

Re: [HACKERS] 8.3 vs HEAD difference in Interval output?

2008-09-15 Thread Ron Mayer
Kevin Grittner wrote: ...not the only place where the float-timestamps code has rounding behavior that doesn't appear in the integer-timestamps code. ... I find the results on 8.3.3 with integer timestamps surprising: Agreed it's surprising and agreed there are more places. Sounds like I

Re: [HACKERS] 8.3 vs HEAD difference in Interval output?

2008-09-15 Thread Ron Mayer
Tom Lane wrote: This is not the only place where the float-timestamps code has rounding behavior that doesn't appear in the integer-timestamps code. Yeah... For that matter, I find this surprising as well: regression=# select '0.7 secs'::interval, ('7 secs'::interval/10); interval |

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-15 Thread Ron Mayer
Tom Lane wrote: support for SQL-spec interval literals. I decided to go look at exactly how unfinished it was, and it turns out that it's actually pretty close. Hence the attached proposed patch ;-) Is this code handling negative interval literals right? I think I quote the relevant spec part

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

2008-09-15 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Is this code handling negative interval literals right? I think I quote the relevant spec part at the bottom. We support independent signs for the different components of the Even so it surprises me that: '-1-1'::interval gives me a day

[HACKERS] Patch for SQL-standard negative valued year-month literals

2008-09-16 Thread Ron Mayer
Tom Lane wrote: ... SQL-spec interval literals. I decided to go look at exactly how unfinished it was, and it turns out that it's actually pretty close. Hence the attached proposed patch ;-) Short summary: I think this patch fixes a bug with sql-spec negative interval literals. Longer. I

Re: [HACKERS] Patch for SQL-standard negative valued year-month literals

2008-09-16 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Short summary: I think this patch fixes a bug with sql-spec negative interval literals. Hmm. I'm a bit concerned about possible side-effects on other cases: what had been seen as two separate tokens will now become one token for *all

Re: [HACKERS] Patch for SQL-standard negative valued year-month literals

2008-09-16 Thread Ron Mayer
Tom Lane wrote: If I read SQL 200N's spec correctly select interval '-1 1:00:00'; should mean-1 days -1 hours, yet 8.3 sees it as -1 days +1 hours. I think we are kind of stuck on this one. If we change it, then how would one represent -1 days +1 hours? The spec's format is only

Re: [HACKERS] Patch for SQL-standard negative valued year-month literals

2008-09-17 Thread Ron Mayer
Tom Lane wrote: Stephen R. van den Berg [EMAIL PROTECTED] writes: Intervals are a scalar, not an addition of assorted values, alternating signs between fields would be wrong. Sorry, you're the one who's wrong on that. We've treated intervals as three independent fields for years now (and

[HACKERS] Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle

2008-09-17 Thread Ron Mayer
Tom Lane wrote: In fact, given that we are now somewhat SQL-compliant on interval input, a GUC that selected PG traditional, SQL-standard, or ISO 8601 interval output format seems like it could be a good idea. Short summary: The attached patch (1) adds a new GUC called IntervalStyle

Re: [HACKERS] Do we really need a 7.4.22 release now?

2008-09-18 Thread Ron Mayer
Steve Crawford wrote: Tom Lane wrote: Yeah. What this is about is how long the *community* supports 7.4... Is there any way to poll the community and see how much people in the community care about 7.4 community support? It seems possible that most people with large important 7.4 systems

[HACKERS] Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle

2008-09-20 Thread Ron Mayer
Ron Mayer wrote: Tom Lane wrote: ...GUC that selected PG traditional, SQL-standard... interval output format seems like it could be a good idea. This is an update to the earlier SQL-standard-interval-literal output patch that I submitted here: http://archives.postgresql.org/message-id

Re: [HACKERS] Initial prefetch performance testing

2008-09-22 Thread Ron Mayer
Gregory Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: I'm not in favour of introducing the concept of spindles In principle I quite strongly disagree with this Number of blocks to prefetch is an internal implementation detail that the DBA has absolutely no way to know what the

[HACKERS] Interval literal rounding bug(?) and patch.

2008-09-22 Thread Ron Mayer
I think it's a bug that these 3 different ways of writing 0.7 seconds produce different results from each other on HEAD. head=# select interval '0:0:0.7', interval '@ 0.70 secs', interval '0.7 seconds'; interval |interval |interval

Re: [HACKERS] Initial prefetch performance testing

2008-09-22 Thread Ron Mayer
Gregory Stark wrote: Ron Mayer [EMAIL PROTECTED] writes: I'd rather a parameter that expressed things more in terms of measurable quantities [...] ...What we're dealing with now is an entirely orthogonal property of your system: how many concurrent requests can the system handle. Really

Re: [HACKERS] PostgreSQL future ideas

2008-09-23 Thread Ron Mayer
Gevik Babakhani wrote: Has there been any idea to port PG to a more modern programming language like C++? Of course there are some minor obstacles like a new OO design, this being a gigantic task to perform and rewriting almost everything etc... I am very interested to hear your opinion.

[HACKERS] Interval output bug in HAVE_INT64_TIMESTAMP

2008-10-02 Thread Ron Mayer
HEAD and 8.3. Ron Mayer == ON HEAD regression=# set datestyle to sql; SET regression=# select '-10 mons -3 days +03:55:06.70

[HACKERS] Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle

2008-10-02 Thread Ron Mayer
Ron Mayer wrote: Ron Mayer wrote: Tom Lane wrote: ...GUC that selected PG traditional, SQL-standard... interval output format seems like it could be a good idea. This is an update to the earlier SQL-standard-interval-literal output patch that I submitted here: http://archives.postgresql.org

[HACKERS] Patch for ISO-8601-Interval Input and output.

2008-10-02 Thread Ron Mayer
Ron Mayer wrote: Tom Lane wrote: In fact, given that we are now somewhat SQL-compliant on interval input, a GUC that selected PG traditional, SQL-standard, or ISO 8601 interval output format seems like it could be a good idea. This patch (that works on top of the IntervalStyle patch I posted

Re: [HACKERS] Interval output bug in HAVE_INT64_TIMESTAMP

2008-10-02 Thread Ron Mayer
Tom Lane wrote: Yeah, bug all the way back --- applied. I don't much like the forced rounding to two digits here, but changing that doesn't seem like material for back-patching. Are you going to fix that up while working on your other patches? Gladly. I hate that too. I think I can also

Re: [HACKERS] Interval output bug in HAVE_INT64_TIMESTAMP

2008-10-02 Thread Ron Mayer
Ron Mayer wrote: Tom Lane wrote: Yeah, bug all the way back --- applied. I don't much like the forced rounding to two digits here, but changing that doesn't seem like material for back-patching. Are you going to fix that up while working on your other patches? Gladly. I hate that too

Re: [HACKERS] 8.3 vs HEAD difference in Interval output?

2008-10-09 Thread Ron Mayer
: Ron Mayer [EMAIL PROTECTED] writes: [some other interval rounding example] I don't much like the forced rounding to two digits here, but changing that doesn't seem like material for back-patching. Are you going to fix that up while working on your other patches? -- Sent via pgsql-hackers

Re: [HACKERS] 8.3 vs HEAD difference in Interval output?

2008-10-09 Thread Ron Mayer
Tom Lane wrote: In the integer-timestamp world we know that the number is exact in microseconds. We clearly ought to be prepared to display up to six fractional digits, but suppressing trailing zeroes in that seems appropriate. Great. We could try to do the same in the float case, but I'm a

Re: [HACKERS] 8.3 vs HEAD difference in Interval output?

2008-10-09 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: Tom Lane wrote: We could try to do the same in the float case, but I'm a bit worried about finding ourselves showing 1234567.79 ... If I understand the code right [I didn't...] The problem is ... seconds field that includes hours

Re: [HACKERS] How is random_page_cost=4 ok?

2008-10-10 Thread Ron Mayer
Tom Lane wrote: In particular, if the OS lays out successive file pages in a way that provides zero latency between logically adjacent blocks, I'd bet a good bit that a Postgres seqscan would miss the read timing every time, and degrade to handling about one block per disk rotation. Unless the

Re: [HACKERS] The Axe list

2008-10-10 Thread Ron Mayer
Josh Berkus wrote: intagg: ... Has not been updated since 2001. Really? Just a couple years ago (2005) bugs we reported were still getting fixed in it: http://archives.postgresql.org/pgsql-bugs/2005-03/msg00202.php http://archives.postgresql.org/pgsql-bugs/2005-04/msg00165.php Here's one

Re: [HACKERS] The Axe list

2008-10-11 Thread Ron Mayer
[EMAIL PROTECTED] wrote: So it seems that intagg should rather live in a section examples than in contrib? Perhaps. Seems my old intagg use case from 8.1 is not really needed anymore since it seems ANY got much smarter since then. Cool.

Re: [HACKERS] The Axe list

2008-10-11 Thread Ron Mayer
Josh Berkus wrote: So it sounds like intagg is still in use/development. But ... is it more of an example, or is it useful as a type/function in production? Where I work we (and our customers) use it in our production systems. At first glance it seems our reasons for using it are mostly

Re: [HACKERS] Cross-column statistics revisited

2008-10-16 Thread Ron Mayer
Robert Haas wrote: I think the real question is: what other kinds of correlation might people be interested in representing? Yes, or to phrase that another way: What kinds of queries are being poorly optimized now and why? The one that affects our largest tables are ones where we have an

Re: [HACKERS] Cross-column statistics revisited

2008-10-16 Thread Ron Mayer
Josh Berkus wrote: Yes, or to phrase that another way: What kinds of queries are being poorly optimized now and why? Well, we have two different correlation problems. One is the problem of dependant correlation, such as the 1.0 correlation of ZIP and CITY fields as a common problem. This

Re: [HACKERS] Cross-column statistics revisited

2008-10-17 Thread Ron Mayer
Tom Lane wrote: A bad estimate for physical-position correlation has only limited impact, Ah! This seems very true with 8.3 but much less true with 8.0. On a legacy 8.0 system I have a hard time avoiding cases where a query like select * from addresses where add_state_or_province = 'CA';

Re: [HACKERS] new correlation metric

2008-10-27 Thread Ron Mayer
Jeff Davis wrote: Currently, we use correlation to estimate the I/O costs of an index scan. However, this has some problems: It certainly helps some cases. Without the patch, the little test script below ends up picking the third fastest plan (a seq-scan) instead of a faster bitmapscan, or an

Re: [HACKERS] new correlation metric

2008-10-27 Thread Ron Mayer
Tom Lane wrote: Ron Mayer [EMAIL PROTECTED] writes: ...bitmap cost estimates didn't also change much By definition, a bitmap scan's cost isn't affected by index order correlation. No? I think I understand that for index scans the correlation influenced how many data pages

  1   2   3   4   >