*snip*
One pretty major fly in the ointment is that neither Hot Standby nor
Streaming Replication has been committed or shows much sign of being
about to be committed. I think this is bad. These are big features
that figure to have some bugs and break some things. If they're not
committed in
I'm not sure if it can be finished until the start of the next CF, but
I've been working on $subject. This work intends to extend current
limited frame types of window functions such like below;
- ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
- ORDER BY x RANGE BETWEEN CURRENT ROW AND f FOLLOWI
Hitoshi Harada wrote:
> That means moving average is initialized again on frame-off situation
> as the frame moves down. I know that may kill it's performance but
> reasons above result in my proposing design.
Yeah, we need the reinitialization support to handle the generic case.
One idea is to t
On Sun, 2009-11-08 at 21:17 +, Simon Riggs wrote:
> Not sure I see why this is good. Why is issuing CREATE TYPE so much
> easier than using CREATE TABLE? Is it worth the extra syntax and code to
> support it? Can we do anything additional as a result of this?
These are tools to improve databas
On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
> I'm not sure if it can be finished until the start of the next CF,
> but I've been working on $subject. This work intends to extend
> current limited frame types of window functions such like below;
This is very, very exciting. Is
> "Heikki" == Heikki Linnakangas
> writes:
Heikki> Yeah, we need the reinitialization support to handle the generic case.
Heikki> One idea is to take a copy of the state datum after each row.
Some existing aggregates, notably array_agg, rely on the assumption
that this never happens.
2009/11/9 Andrew Gierth :
>> "Heikki" == Heikki Linnakangas
>> writes:
>
> Heikki> Yeah, we need the reinitialization support to handle the generic
> case.
>
> Heikki> One idea is to take a copy of the state datum after each row.
>
> Some existing aggregates, notably array_agg, rely on
2009/11/9 David Fetter :
> On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
>> I'm not sure if it can be finished until the start of the next CF,
>> but I've been working on $subject. This work intends to extend
>> current limited frame types of window functions such like below;
>
>
Heikki Linnakangas writes:
> One idea is to take a copy of the state datum after each row. Then,
> instead of initializing the aggregate from scratch, you can "roll back"
> to an earlier copied state. It doesn't always help, but might be a part
> of the solution.
That requires that you know how t
On Mon, Nov 09, 2009 at 11:20:39PM +0900, Hitoshi Harada wrote:
> 2009/11/9 David Fetter :
> > On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
> >> I'm not sure if it can be finished until the start of the next CF,
> >> but I've been working on $subject. This work intends to extend
On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> Log Message:
> ---
> Rewrite GEQO's gimme_tree function so that it always finds a legal join
> sequence, even when the input "tour" doesn't lead directly to such a sequence.
> The stack logic that was added in 2004 only supported cases whe
On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> > Log Message:
> > ---
> > Rewrite GEQO's gimme_tree function so that it always finds a legal join
> > sequence, even when the input "tour" doesn't lead directly to such a
> > sequen
On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
> On Monday 09 November 2009 16:18:10 Robert Haas wrote:
>> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
>> > Log Message:
>> > ---
>> > Rewrite GEQO's gimme_tree function so that it always finds a legal join
>> > sequence, even wh
2009/11/10 David Fetter :
> On Mon, Nov 09, 2009 at 11:20:39PM +0900, Hitoshi Harada wrote:
>> 2009/11/9 David Fetter :
>> > On Mon, Nov 09, 2009 at 06:39:54PM +0900, Hitoshi Harada wrote:
>> >> I'm not sure if it can be finished until the start of the next CF,
>> >> but I've been working on $subje
On Monday 09 November 2009 16:23:52 Robert Haas wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> >> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
> >> > Log Message:
> >> > ---
> >> > Rewrite GEQO's gimme_tree f
On Mon, Nov 9, 2009 at 10:27 AM, Andres Freund wrote:
> On Monday 09 November 2009 16:23:52 Robert Haas wrote:
>> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund wrote:
>> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
>> >> On Sun, Jul 19, 2009 at 4:00 PM, Tom Lane wrote:
>> >> > Log M
ERROR: could not read directory "pg_tblspc/16464": Invalid
argument
STATEMENT: DROP TABLESPACE testspace;
Hmm ... can't reproduce this here, not even on OSX. From the
version
number I suspect you are using unreleased Snow Leopard. I'd venture
it's a newly-introduced kernel bug and you n
On Mon, Nov 9, 2009 at 10:18 AM, Robert Haas wrote:
> I think I just ran smack dab into this bug on 8.3.8 (RPM:
> postgresql-8.3.8-1.fc10.i386). I had a query that wasn't coming out
> very well with the default settings so I raised the collapse limits
> and let GEQO have a crack at it. This was
On Monday 09 November 2009 16:28:46 Robert Haas wrote:
> On Mon, Nov 9, 2009 at 10:27 AM, Andres Freund wrote:
> > On Monday 09 November 2009 16:23:52 Robert Haas wrote:
> >> On Mon, Nov 9, 2009 at 10:21 AM, Andres Freund
wrote:
> >> > On Monday 09 November 2009 16:18:10 Robert Haas wrote:
> >>
On Nov 7, 1:21 am, t...@sss.pgh.pa.us (Tom Lane) wrote:
> I believe we had consensus that plpgsql should offer the following three
> behaviors when a name in a SQL query could refer to either a plpgsql
> variable or a column from a table of the query:
> * prefer the plpgsql variable (plpgsq
Robert Haas writes:
> I've stopped the query more than 10 times now and EVERY SINGLE ONE
> finds it in list_concat_unique_ptr(). :-(
Too bad you don't have debug symbols ... it'd be interesting to see
how long that list is.
> It's also using about 12x as much RAM as the GEQO version.
No surpri
Hey Jan, did you get any response to that bug report? Somebody else
dug up a document suggesting that this might be intentional on Apple's
part:
http://archives.postgresql.org/pgsql-bugs/2009-11/msg00040.php
i was not subscribed to pgsql-bugs list. i have read this message now
and
see he is r
On Nov 7, 1:21 am, t...@sss.pgh.pa.us (Tom Lane) wrote:
> I believe we had consensus that plpgsql should offer the following three
> behaviors when a name in a SQL query could refer to either a plpgsql
> variable or a column from a table of the query:
> * prefer the plpgsql variable (plpgsq
On Fri, Nov 06, 2009 at 09:53:20PM -0500, Andrew Dunstan wrote:
>
>
> Joshua Tolley wrote:
>> I looked through the
>> regression tests and didn't find any that used plperl -- should we add one
>> for
>> this (or for this and all kinds of other stuff)? Is there some way to make
>> running the regr
Jan Otto writes:
> a quick check on mac os x 10.4 und 10.5 confirmed that this behaviour/
> bug is not present like described in this article. probably it was in
> 10.0.x... i have no older version of mac os x available here to check.
Yeah, I thought we'd probably have heard about it before now i
On Mon, Nov 9, 2009 at 3:01 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> One idea is to take a copy of the state datum after each row. Then,
>> instead of initializing the aggregate from scratch, you can "roll back"
>> to an earlier copied state. It doesn't always help, but might be a part
On Mon, Nov 09, 2009 at 10:01:53AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > One idea is to take a copy of the state datum after each row. Then,
> > instead of initializing the aggregate from scratch, you can "roll back"
> > to an earlier copied state. It doesn't always help, but mig
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name "operator-based exclusion
constraints", so we can also just use that name. Or, just "exclusion
constraints".
(exclusion constraints)++
David
On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> I've stopped the query more than 10 times now and EVERY SINGLE ONE
>> finds it in list_concat_unique_ptr(). :-(
>
> Too bad you don't have debug symbols ... it'd be interesting to see
> how long that list is.
[ teaches se
On Mon, Nov 9, 2009 at 5:12 PM, David E. Wheeler wrote:
> On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
>
>> Either of those names are fine with me, too. The current name is a
>> somewhat shortened version of the name "operator-based exclusion
>> constraints", so we can also just use that name. Or
Greg Stark writes:
> On Mon, Nov 9, 2009 at 3:01 PM, Tom Lane wrote:
>> That requires that you know how to copy the aggregate's state. You do
>> not. (In some cases the aggregate function has extra state besides the
>> nominal transition datum...)
> That's relatively unusual and usually a bad
Robert Haas writes:
> On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
>> Too bad you don't have debug symbols ... it'd be interesting to see
>> how long that list is.
> I stopped it a couple of times. Lengths of list1, list2 respectively:
> 8876, 20
> 14649, 18
> 15334, 10
> 17148, 18
> 18173
On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 9, 2009 at 10:57 AM, Tom Lane wrote:
>>> Too bad you don't have debug symbols ... it'd be interesting to see
>>> how long that list is.
>
>> I stopped it a couple of times. Lengths of list1, list2 respectively:
Greg Stark escribió:
> Out of curiosity, is this feature at all similar to SQL assertions?
> What would we be missing to turn this into them?
I see no relationship to assertions. Those are not tied to any
particular table, and are defined with any random expression you care to
think of.
--
Alv
Tom Lane escribió:
> Andrew Dunstan writes:
> > This is a pretty good short explanation of how to deal with shift/reduce
> > problems in bison. With your permission I'm going to copy it to the Wiki
>
> If you like, but I think the part about figuring out which production
> is the problem seemed
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a good
> chunk of the September CommitFest, I am feeling a bit burned out.
Dave, Selena and I will all be in Japan during the first week of the CF.
I can help af
On Mon, 2009-11-09 at 18:03 +, Greg Stark wrote:
> Out of curiosity, is this feature at all similar to SQL assertions?
> What would we be missing to turn this into them?
I addressed that here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00049.php
The exclusion constraint mechanis
Tom Lane wrote:
> Greg Stark writes:
> > While i agree this looks nicer I wonder what it does to things like
> > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > files. I'm not sure our old format was so great for this so maybe this
> > is actually an improvement I'm asking
Andrew Dunstan wrote:
> >You can set the field separator to ',' but you can't do a
> > \pset format csv
> >and get CSV with correct quoting, escaping etc AFAICS. It'll
> >still break on line wrapping if wrapping is enabled, and with
> >newlines in the data.
> >
> >If that would be a useful addit
Tom Lane wrote:
> Under old-style semantics this will do what the programmer thought.
> Under Oracle semantics it will return the first table row. If
> do-something is security critical then this is enough to call it
> an exploit. The reverse direction (code meant for Oracle behavior
> breaks und
On Mon, 2009-11-09 at 12:15 +0200, Peter Eisentraut wrote:
> > Is this required by the standard or are we going past the standard?
>
> This is part of the SQL standard.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Robert Haas wrote:
> On Thu, Oct 22, 2009 at 2:28 PM, Josh Berkus wrote:
> > All,
> >
> > Wouldn't per *tablespace* costs make more sense?
> >
> > --Josh
>
> Yes, we already had several votes in favor of that approach. See upthread.
Added to TODO:
Allow per-tablespace random_page_cost
Simon Riggs wrote:
On Thu, 2009-10-08 at 11:50 -0400, Tom Lane wrote:
Robert Haas writes:
Subcommitting every single row is going to be really painful,
especially after Hot Standby goes in and we have to issue a WAL record
after every 64 subtransactions (AIUI).
Yikes ... I ha
I have applied the attached patch to document that FOUND is not affected
by EXECUTE, while GET DIAGNOSTICS is.
---
Robert Haas wrote:
> On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule
> wrote:
> > 2009/10/23 Robert Haas :
Andrew Dunstan writes:
> Simon Riggs wrote:
>> HS writes a WAL record for subtransactions at the point that the subxid
>> cache overflows for any single transaction. Current cache size = 64.
>> Top-level transaction then writes one additional WAL record every
>> additional 64 subxids after that. T
I wrote:
> My inclination is to continue assuming that the EINVAL is a new bug
> introduced in Snow Leopard. I sure hope they fix it in 10.6.2 though.
> If they don't, we may have to think about a workaround, messy as that
> will apparently be.
10.6.2 is out, and it appears to fix the bug --- if
On Mon, Nov 09, 2009 at 09:01:14PM -0500, Bruce Momjian wrote:
>
> I have applied the attached patch to document that FOUND is not affected
> by EXECUTE, while GET DIAGNOSTICS is.
One minor nit here:
> Index: doc/src/sgml/plpgsql.sgml
> ===
I'm working on partitioning syntax, amd encountered a dependency issue.
When we define partition, also create an implicit CHECK constraint.
The constraint should be kept until the pg_inherits entry is removed.
But we cannot have a dependency from the constraint to the inheritance.
An idea is addi
On tis, 2009-11-10 at 16:22 +0900, Itagaki Takahiro wrote:
> I'm working on partitioning syntax, amd encountered a dependency issue.
> When we define partition, also create an implicit CHECK constraint.
> The constraint should be kept until the pg_inherits entry is removed.
> But we cannot have a d
49 matches
Mail list logo
