Re: [HACKERS] configurability of OOM killer

ur VM accounting is wildly inaccurate". We'd still end up with a > postmaster at more risk than we'd like, but at least not at dozens of > times more risk than any backend. > I agree completely, and that's exactly the argument I tried to make on LKML a year ago

Re: [HACKERS] configurability of OOM killer

with 4GB of memory, badness() might plausibly think that This overcounting that punishes postgresql is the problem. Regards, Jeff Davis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] configurability of OOM killer

o preferentially kill. > > Wouldn't the more general rule that Jeff Davis pointed out upstream > make more sense? > > That shared memory of the children should not be added to the size > of the parent process multiple times regardless of if something's > an essential

Re: [HACKERS] pg_dump additional options for performance

the multi-file options provide any new functionality? Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

y INSERT ... SELECT isn't good enough. If the records really are in their internal format, then INSERT ... SELECT seems like the way to go. 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 4/4] Add tests to dblink covering use of COPY TO FUNCTION

ode > (binary mode has a header that cannot be so neatly catenated). This > is something that's pretty hard to enable with any automatic > startup-work-cleanup approach. What if the network buffer is flushed in the middle of a line? Is that possible, or is there a guard against

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

On Sun, 2009-11-29 at 18:53 -0800, Daniel Farina wrote: > On Sun, Nov 29, 2009 at 6:35 PM, Jeff Davis wrote: > > What if the network buffer is flushed in the middle of a line? Is that > > possible, or is there a guard against that somewhere? > > What do you mean? They b

Re: [HACKERS] Listen / Notify - what to do when the queue is full

I haven't looked at everything yet, but this seems like it's in reasonable shape from a high level. Joachim, can you clean the patch up, include docs, and fix the tests? If so, I'll do a full review. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] New VACUUM FULL

mitter" tonight. Of course, a committer can take a look at it sooner, if they have 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] New VACUUM FULL

UUM > > FULL" defaults to "replace" for user tables and "inplace" for system > > tables. I tried to make that more clear in my documentation suggestions. > > * There are some windows line endings in the patch, which should be > > removed. Great

Re: [HACKERS] operator exclusion constraints

me you're referring to the name used in documentation and error messages. I didn't see a clear consensus, but the relevant thread is here: http://archives.postgresql.org/message-id/1258227283.708.108.ca...@jdavis "Exclusion Constraints" is fine with me, as are the other options listed

Re: [HACKERS] Listen / Notify - what to do when the queue is full

don't have much time to hand the patch back and forth before we're out of 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] operator exclusion constraints

On Fri, 2009-12-04 at 11:35 -0500, Tom Lane wrote: > Unless there's loud squawks I'm going to exercise committer's > prerogative and make all the docs and messages just say "exclusion > constraint". Sounds fine to me. Regards, Jeff Davis -- Sent via

Re: [HACKERS] New VACUUM FULL

On Fri, 2009-12-04 at 09:20 +, Simon Riggs wrote: > On Tue, 2009-12-01 at 01:43 -0800, Jeff Davis wrote: > > Marking as ready. > > You're saying its ready, yet there are 3 additional suggestions patches > attached here. Please can you resolve these and re-submit a si

Re: [HACKERS] New VACUUM FULL

after he's convinced that it works. I tested a variety of situations during my review, and everything worked as I expected. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] New VACUUM FULL

simplest tests, they aren't easily moved to pg_regress. For instance, how do you tell if a user table's relfilenode actually changed? Easy to do manually, but tough to do with pg_regress. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] operator exclusion constraints

for the two cases) rather than changing the algorithm. 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

Re: [HACKERS] operator exclusion constraints

ean "equal". Changing in the other direction is bad, as well. I know operators mostly follow convention most of the time, but I'm concerned with the subtle (and surprising) differences. But if someone is changing a column type, which causes a table rewrite, hopefully they'v

Re: [HACKERS] operator exclusion constraints

On Mon, 2009-12-07 at 00:26 -0500, Tom Lane wrote: > Jeff Davis writes: > > [ exclusion constraint patch ] > > Applied after quite a lot of editorialization. For future reference, > here is a summary of what I did: Thank you for the suggestions, and the other constructiv

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

On Mon, 2009-12-07 at 23:12 -0300, Alvaro Herrera wrote: > Perhaps > table_exclusion = {on, off, partition} Sounds good to me. > Of course, constraint_exclusion should continue to work as a synonym for > backwards compatibility, but it wouldn't be documented. +1. Regards,

Re: [HACKERS] Exclusion Constraint vs. Constraint Exclusion

ost among the other emails. I put one such mention on the commitfest page so that it wouldn't be lost, but I suppose it was anyway: http://archives.postgresql.org/message-id/1258227283.708.108.ca...@jdavis Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Range types

r discrete ranges as well. If we did, then we would think that [5, 10] and [5, 11) were not equal, but they are. Similarly, we would think that [5, 10] and [11, 12] were not adjacent, but they are. So there are certainly some user-visible API differences between the two, and I don't think those di

Re: [HACKERS] Range types

If so, I don't think it's necessary if we expose the API differences I outlined in another email in this thread. Also, that would mean that we don't need a granule for float, because we can already treat it as discrete*. Regards, Jeff Davis *: nextafter() allows you to incremen

Re: [HACKERS] Range types

t really use it that way -- as Tom points out, typmod is not passed along to functions that take the value. But if it were a part of the type, then I would certainly agree. 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

the number of types that are > really discrete in this sense is very small, like maybe just ints and > enums.) I think "countable" is a more accurate word than "discrete". Strings are discrete but not countable. Regards, Jeff Davis -- Sent via pgsql-hackers m

Re: [HACKERS] Range types

MP, the difference type would be INTERVAL) and a couple support functions. This might be more flexible, and it would obviate the need for marking operator families. If the second approach seems promising, we can hammer out a real proposal and see if it's viable. Regards, Jeff Davis

Re: [HACKERS] Range types

ge fraction of our user-base doesn't understand that floats are > inexact :-( I don't know how we can decide such a thing. Do you have any ideas? Perhaps we can compromise and restrict the support functions to C? That might be a high-enough wall, and of course it would keep non-supe

Re: [HACKERS] Range types

r the int64 timestamps. 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] Range types

een it) that isn't equally solvable (or better) using some other method * would impose that extra 8-byte storage burden on people who may not need any flag bits 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

ns will always be smart enough to sort it out for themselves. 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

least in some circumstances, it's important to be able to display the same value in different formats -- e.g. [1, 3) or [1, 2], depending on what the application expects. Similar to a timezone adjustment. Regards, Jeff Davis [1] "Temporal Data and the Relational Model" by

Re: [HACKERS] Range types

ith a single timestamp and save 16 bytes per record". Or maybe "Why waste the bytes? I'll just store two timestamps". 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

For another author that apparently likes to deal with discrete time, how about "Developing Time-Oriented Database Applications in SQL" by Snodgrass. It's free to download online, I believe. 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

only way I can see making that > work is if we specify a scale for timestamptz, and that strikes me as > a big change to its semantics. It's already useful at the microsecond precision level. Also, the granule could be defined for the range type (as Scott suggested) rather than the t

Re: [HACKERS] Range types

thing that everyone wants, including flags to indicate special values. * discrete range granule is specified explicitly, so it's not an "implementation detail" * discrete ranges can have a compact representation * discrete ranges would still have room for flags to indicat

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 12:42 -0500, Robert Haas wrote: > On Wed, Dec 16, 2009 at 12:31 PM, Jeff Davis wrote: > > There's one problem, and that's for timestamptz ranges with intervals > > that include days and months. Timezone adjustments are just not > > well-define

Re: [HACKERS] Range types

format. You're creating a whole lot of work for > yourself and a whole lot of user-visible corner cases in return for > what ultimately isn't much. This isn't just to shave bytes. It's also because I like the semantics of discrete ranges for many cases. Regards,

Re: [HACKERS] Range types

rete ranges will be hard-wired, that's way too restrictive. If nothing else, it makes some system types "special" which we have not done very many other places. 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

things with various flag settings (because it has a flag byte in the latest proposal). I said so explicitly. 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

from earlier proposals? Earlier you proposed that we hard-wire the set of types that are allowed to be used for discrete ranges: http://archives.postgresql.org/pgsql-hackers/2009-12/msg01278.php Regards, Jeff Davis [1] "Temporal Data and the Relational Model" by C.J. Date, et al. [2] "Develo

Re: [HACKERS] Range types

n't suggest that the ipv4 data type's next() function should skip over addresses that aren't in a valid subnet on your network. But you seem to think those make useful discrete ranges. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] Range types

ide the necessary functions. 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] About the CREATE TABLE LIKE indexes vs constraints issue

I adjust it from there. Are there people out there who use LIKE in their production schema files? 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] Serializable implementation

t;repeatable read" for snapshot isolation (perhaps with a compatibility GUC existing for a while to get the old behavior). However, I don't know what you mean by "get-a-new-snapshot strategy" or how it is different from the current read committed behavior. We obviously want to be careful

[HACKERS] special cases of true serializability

ility? 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] Serializable implementation

and implement designs. 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 4/4] Add tests to dblink covering use of COPY TO FUNCTION

on." http://archives.postgresql.org/pgsql-hackers/2009-11/msg01555.php David Fetter had some ideas as well: http://archives.postgresql.org/pgsql-hackers/2009-11/msg01826.php Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

Regardless, I think there needs to be a way to pass arguments to the functions (at least the startup one). The obvious use case is to pass the destination table name, so that you don't have to define a separate target for each destination table. Regards, Jeff Davis -- Sent via p

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

hat they intended to actually use CREATE AGGREGATE, although I could be mistaken. 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] Serializable Isolation without blocking

e the various issues as they progress? If there was an existing wiki page I couldn't find it. 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] true serializability and predicate locking

. That way, the conflict can be detected if an INSERT tries to update the predicate of a page to something that the search may have matched. If the index was GIN instead of GiST, I think the fastupdate feature would cause a problem, though (as Greg brought up). Fastupdate may need to be disabled when u

Re: [HACKERS] true serializability and predicate locking

ere are obvious down-sides to such a strategy, so I'm forced > into the position of saying, with regards to most potential > optimizations, "we'll cross that bridge when we come to it" -- > knowing full well that many optimizations will indeed be necessary > befo

Re: [HACKERS] true serializability and predicate locking

on for those kinds of functions. So I don't see this as a major problem. My biggest worry is that a predicate locking scheme like this will be fairly difficult to implement and expensive to execute. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

Re: [HACKERS] Listen / Notify - what to do when the queue is full

er? Sure, I'll review it. 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] advantage of new vacuum

still uses the old behavior. VACUUM FULL INPLACE forces the old behavior on user tables, as well. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Serializable Isolation without blocking

g (as I understand it) is that the lock conflicts with tuples that don't even exist yet. We can tack them on to any structure that's convenient, of course. But just because you want to implement them by locking a few index pages (assuming there is an index) doesn't mean we sho

Re: [HACKERS] Serializable Isolation without blocking

ase. I think we are in agreement. I was responding to Robert Haas's comment, because it sounded like he didn't understand Greg Stark's point. 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] Serializable implementation

-- is highly undesirable (to me at least). It seems much more reasonable to have a "serializable_is_repeatable_read" GUC that defaults to true for a release, then defaults to false, then we may even eventually eliminate it. Regards, Jeff Davis -- Sent via pgsql-ha

Re: [HACKERS] Serializable implementation

have true serializable transactions implemented. Ok, I don't have a strong opinion about that. > It really depends on application code we might > break, which is hard to determine. Well, hopefully it doesn't break anything. Applications asking for SERIALIZABLE should already be ex

Re: [HACKERS] Serializable implementation

the documentation (that I'm aware of). 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] damage control mode

side: I'll take this alarm as a very strong hint that I shouldn't push the "range types" any more until the next development cycle. Particularly because Tom is one of the people with opinions about it, so I don't want to distract him from features submitted several commit

[HACKERS] is this a bug?

create type y as (c char, n int); select ('a', NULL)::y = ('a', NULL)::y; -- TRUE select ('a', NULL) = ('a', NULL); -- NULL I would expect those to evaluate to the same thing. Regards, Jeff Davis -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] is this a bug?

e the issue. 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] Listen / Notify - what to do when the queue is full

f the touchy synchronization steps going on. I find myself trying to make a map of these steps myself. 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] MySQL-ism help patch for psql

ql release, and this would make it easier. Please add the patch to the next commitfest: https://commitfest.postgresql.org/action/commitfest_view?id=6 It's small enough that, if others like it as well, maybe it (or something similar) could still make it in this release. Regards,

Re: [HACKERS] MySQL-ism help patch for psql

w that this is > that command - why not emulate it fully?". Good points. However, it only takes effect in interactive mode, so I don't see it as a promise to do much. I'll make an analogy to: $ git difff git: 'difff' is not a git-command. See 'git --help'.

Re: [HACKERS] MySQL-ism help patch for psql

On Tue, 2010-01-19 at 11:43 -0800, Jeff Davis wrote: > > I'm not convinced that we should start adding syntax helpers like that > > to psql. For now it is an arbitrary subset of MySQL stuff, are we going > > to add oracle/db2/mssql/drizzle/mariadb and whatnot later on? >

Re: [HACKERS] MySQL-ism help patch for psql

On Tue, 2010-01-19 at 20:52 +0100, Stefan Kaltenbrunner wrote: > Jeff Davis wrote: > >> I'm not convinced that we should start adding syntax helpers like that > >> to psql. For now it is an arbitrary subset of MySQL stuff, are we going > >> to add oracle/db

Re: [HACKERS] Listen / Notify - what to do when the queue is full

commit starts > commit to clog > commit to clog > > => Backend 2 will not receive Backend 1's notification. This is the same problem, except that it doesn't matter. A spurious notification is not a bug, right? Regards, Jeff Davis -- Sent vi

Re: [HACKERS] Listen / Notify - what to do when the queue is full

y no worse than what happens now) but the naming > suggested that this'd happen unconditionally. It appears that the locks are only taken when LISTEN or NOTIFY is involved. 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] Listen / Notify - what to do when the queue is full

On Tue, 2010-01-19 at 19:24 -0500, Tom Lane wrote: > Jeff Davis writes: > > I was also worried about holding multiple LWLocks at once -- is such > > practice generally avoided in the rest of the code? > > It's allowed but remember that there is no deadlock detection

Re: [HACKERS] Listen / Notify - what to do when the queue is full

cting transaction-like behavior, except for the NOTIFYs themselves. 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] Listen / Notify - what to do when the queue is full

he above scheme is too complex, we can always use a heavyweight lock. However, there's no pg_listener so it's not obvious what LOCKTAG to use. We can just pick something arbitrary, like the Oid of the new pg_listening() function, I suppose. Is there any precedent for that? Thoughts? Regards,

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote: > On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis wrote: > > Here's the problem as I see it: > > You are writing a lot of true facts but I miss to find a real > problem... What exactly do you see as a problem? I wor

Re: [HACKERS] default_language

legacy behavior, like standard_conforming_strings). If we have a default (for DO and CREATE FUNCTION), why not hard-wire the default to plpgsql? 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] default_language

On Mon, 2010-01-25 at 20:26 -0500, Tom Lane wrote: > So it seems everyone is okay with the latter? (Remove > default_do_language in place of a hard-wired default of "plpgsql", > don't change CREATE FUNCTION's behavior.) +1 Regards, Jeff Davis -- Sent v

Re: [HACKERS] Listen / Notify - what to do when the queue is full

enough by doing the UNLISTEN step in AtCommit_NotifyAfterCommit. I'm still looking through some of the queue stuff, and I'll send an update soon. I wanted to give you some feedback now though. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] SeqScan costs

r cold data? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extending varlena

other complexity. 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] WIP patch: reducing overhead for repeat de-TOASTing

atch helps a lot; but it goes back to the performance of unpatched PostgreSQL for the same plan if the nested loop is inverted, as shown below. Regards, Jeff Davis [ plan estimates are omitted for readability ] --- UNPATCHED --- Nested Loop (actual time=3.021..1020.923 rows

Re: [HACKERS] Planner question

> -Tom Raney > http://archives.postgresql.org/pgsql-general/2008-08/msg00967.php My understanding from that thread is that if one table has high ndistinct and the other has low ndistinct, one plan may require more re-scanning than the other. Regards, Jeff Davis -- Sent via pgsql-hackers

[HACKERS] SQL standard question about Common Table Expressions

f indirection in the 200n standard by using an intervening . I'm not an authority, but I believe this is a mistake. Regards, Jeff Davis * Having AQEk = WQEi disturbs me, too, because in the "Framework" part of the standard, section 6.3.3.1, the definition of contains does not see

[HACKERS] Common Table Expressions (WITH RECURSIVE) patch

: General Rules: 2.c.ix.3.A I will provide comments about the code and documentation soon. This is a very useful feature. 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] Common Table Expressions (WITH RECURSIVE) patch

On Mon, 2008-09-08 at 21:13 +0100, Gregory Stark wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > > * Mutual Recursion: > > > > with recursive > > foo(i) as (values(1) union all select i+1 from bar where i < 10), > > bar(i) as (values(

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

andard says should be rejected. > Jeff> * ORDER BY, LIMIT, and OFFSET are rejected for recursive > Jeff> queries. The standard does not seem to say that these should be > Jeff> rejected. > > Note that supporting those in subqueries (including CTEs) is a separate > opt

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

But it's not at all clear that it would be either > useful or easy to do so. Ok. If it's easy to support it should probably be done. As an aside, you seem to be an expert with the standard, have you had a chance to look at the question I asked earlier?: http://archives.postgresql.o

Re: [HACKERS] SQL standard question about Common Table Expressions

r INTERSECT, but my curiosity got the best of 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] Common Table Expressions (WITH RECURSIVE) patch

> * outer joins on a recursive reference should be blocked: > > > > with recursive foo(i) as > > (values(1) > > union all > > select i+1 from foo left join (values(1)) t on (i=column1)) > > select * from foo; > > > > Cause

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

On Tue, 2008-09-09 at 18:51 +0200, Pavel Stehule wrote: > hmm. I solve similar problem in grouping sets :( etc > How did you solve it? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

etically if we did accept the feature as-is -- the number of evaluations would be documented to be undefined, not N. That would avoid the backwards-compatibility problem. This one point is probably not worth discussing now, because argument #1 and #2 stand on their own. Regards, Jeff Davi

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

important, and important enough to be a showstopper. Tom Lane has suggested that this is a reasonable amount of work to complete, and minor in comparison to the rest of the patch. I think the right approach is to try to complete it so that everyone is happy. I will work on this, but unfortunately

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

to traverse up the parse tree or query tree. I can probably work around these weak points, but I wanted to send the patch to avoid a lot of conflicts or problems later. Tell me whether you think this is moving in the right direction. Regards, Jeff Davis cte_fixparse.gz Description: GNU Zip

Re: [HACKERS] TODO item: adding VERBOSE option to CLUSTER [with patch]

relation on restore and therefore not choose index scans (which is what prompted turning off sync scans for pg_dump). 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] Deriving Recovery Snapshots

Can you explain the situation that would result in an invalid snapshot? 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] new correlation metric

Attached is a patch. We replaced "correlation", but left the name the same (even though that's now a misnomer). We can change it if needed. Comments? Regards, Jeff Davis correlation.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pg

[HACKERS] array_agg and array_accum (patch)

ntributed by Truviso. Regards, Jeff Davis array_agg.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] new correlation metric

t index AMs might want different sorts of > stats. Why can't we just use pg_statistic with the starelid set to the index oid? 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] array_agg and array_accum (patch)

.9 general > rule 8g > I apologize, clearly I skimmed the standard too fast. I'll review the standard, allow array_agg() to collect NULLs, perhaps drop array_accum (if the only difference is the return value on no input), and resubmit with docs. Regards, Jeff Davis -- Se

Re: [HACKERS] array_agg and array_accum (patch)

don't see array_accum() in the standard, I wrote it just as an alternative to array_agg() because I thought array_agg() ignored NULLs. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] array_agg and array_accum (patch)

it is a little annoying to coalesce the result or array_agg(). 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

<    6   7   8   9   10   11   12   13   14   15   >