Gavin Sherry <[EMAIL PROTECTED]> writes:
> We want to answer the following: for each employee: what is their rank in
> terms of salary and what is their rank in terms of age. This query
> answers that:
> select empno, rank() over (order by salary) as srank,
> rank() over (order by age) as arank
Merlin Moncure skrev:
The missing piece of the puzzle is the ability to recover a failed
transaction without issuing a full commit/rollback. This could be a
new flavor of the savepoint command, commit command, or a new command.
As a bonus, upon recovering the transaction you could snap an sql
s
On Fri, 19 Jan 2007, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Fri, 19 Jan 2007, Tom Lane wrote:
> >> Er, what primary key would that be exactly? And even if you had a key,
> >> I wouldn't call joining on it trivial; I'd call it expensive ...
>
> > I should have used sligh
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Fri, 19 Jan 2007, Tom Lane wrote:
>> Er, what primary key would that be exactly? And even if you had a key,
>> I wouldn't call joining on it trivial; I'd call it expensive ...
> I should have used slightly different language. What I meant to say was,
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I suspect the savepoint command is almost never used
> outside of oracle compatibility efforts.
Last I heard, we implemented it because it is in the SQL standard.
I have no idea (nor do I much care) whether it's oracle-compatible.
> BEGIN;
> SAVEPOIN
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ke
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Gu
Darcy Buskermolen wrote:
[snip]
Another thought, is it at all possible to do a partial vacuum? ie spend the
next 30 minutes vacuuming foo table, and update the fsm with what hew have
learned over the 30 mins, even if we have not done a full table scan ?
There was a proposal for this, but
On Sat, 19 Jan 2007, Karen Hill wrote:
> Gavin Sherry wrote:
> > Recenly, I've been researching and putting together a proposal for window
> > functions.
>
> Implementing NULLS FIRST and NULLS LAST appears like another
> challenging step to getting window functions wrapped up. Has your
> research
On Fri, 19 Jan 2007, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > What we want to do is have a kind of 'sub plan' for each aggregate. In
> > effect, the plan might start looking like a directed graph. Here is part
> > of the plan as a directed graph.
>
> >
Added to TODO:
> o Allow multiple vacuums so large tables do not starve small
> tables
>
> http://archives.postgresql.org/pgsql-general/2007-01/msg00031.php
>
> o Improve control of auto-vacuum
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00876.p
Stefan Kaltenbrunner wrote:
> Karen Hill wrote:
> > Gavin Sherry wrote:
> >> Recenly, I've been researching and putting together a proposal for window
> >> functions.
> >
> > Implementing NULLS FIRST and NULLS LAST appears like another
> > challenging step to getting window functions wrapped up.
I've never really been very happy with the decision early on in the
development of nested transactions to use savepoints in the way they
were implemented in the command structure. Savepoints are nearly
useless for sql scripting because there is no way to probe a
transaction and handle error condi
Karen Hill wrote:
> Gavin Sherry wrote:
>> Recenly, I've been researching and putting together a proposal for window
>> functions.
>
> Implementing NULLS FIRST and NULLS LAST appears like another
> challenging step to getting window functions wrapped up. Has your
> research lead you to any ideas
Gavin Sherry wrote:
> Recenly, I've been researching and putting together a proposal for window
> functions.
Implementing NULLS FIRST and NULLS LAST appears like another
challenging step to getting window functions wrapped up. Has your
research lead you to any ideas on what your strategy for NULL
Tom Lane wrote:
Perhaps we could extend pg_regress to allow "--max-connections=auto"
which would instruct it to set its connection limit to the server's
actual max_connections minus superuser reserved slots (and probably
minus a couple more to allow for backend shutdown time etc). Then the
buil
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe what we really ought to do is pick an internal max_connections
> value that exceeds what the max_connections GUC parameter say, adjusting
> per autovacuum configuration.
That's just cosmetic; it doesn't address the real issue, which is that
if SHM
Gavin Sherry <[EMAIL PROTECTED]> writes:
> What we want to do is have a kind of 'sub plan' for each aggregate. In
> effect, the plan might start looking like a directed graph. Here is part
> of the plan as a directed graph.
>GroupAggregate
> /
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I noticed today on my own machine several strange pauses while running
>> the serial regression tests ---
> Do those explain what you are seeing?
No, those are expected. I'm having a hard time reproducing the behavior
right now, but
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> SELECT *
>> FROM a LEFT JOIN
>> (SELECT * FROM b JOIN c ON b.y = c.z WHERE b.y = 10) ss
>> ON a.x = ss.y
>> WHERE a.x = 42;
>>
>> ... In this example, notice also that
>> a.x = ss.y (really a.x = b.y) is not an equivale
Stefan Kaltenbrunner wrote:
> Alvaro Herrera wrote:
> > All our Windows buildfarm machines are failing. AFAICT, the first
> > failure was on Yak,
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=yak&dt=2007-01-16%2021:55:20
> >
> > and the last successful run just before that seems to
Stefan Kaltenbrunner wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
yeah - looks like it's the autovacuum change - snake is now passing the
numeric-test but still fails the stats one ...
Interesting -- both yak and snake are failing in a
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Stefan Kaltenbrunner wrote:
>
>>> yeah - looks like it's the autovacuum change - snake is now passing the
>>> numeric-test but still fails the stats one ...
>> Interesting -- both yak and snake are failing in a very similar way.
>> I'll investigate
On Friday 19 January 2007 01:47, Simon Riggs wrote:
> On Tue, 2007-01-16 at 07:16 -0800, Darcy Buskermolen wrote:
> > On Tuesday 16 January 2007 06:29, Alvaro Herrera wrote:
> > > elein wrote:
> > > > Have you made any consideration of providing feedback on autovacuum
> > > > to users? Right now we
Roman Kononov wrote:
> On 12/27/2006 01:15 PM, Tom Lane wrote:
> > I'm not convinced that you're fixing things so much as doing your best
> > to destroy IEEE-compliant float arithmetic behavior.
> >
> > I think what we should probably consider is removing CheckFloat4Val
> > and CheckFloat8Val alto
Tom Lane wrote:
> I noticed today on my own machine several strange pauses while running
> the serial regression tests --- the machine didn't seem to be hitting
> the disk nor sucking lots of CPU, it just sat there for several seconds
> and then picked up again. I wonder if that's related. It su
Tom Lane writes:
> Attached is some material from an updated src/backend/optimizer/README
> that describes the optimization principles that the EquivalenceClass
> rewrite is depending on. Can anyone see any holes in the logic?
Sounds good, I can see no holes.
> SELECT *
> FROM a LE
On Tue, 2007-01-16 at 07:16 -0800, Darcy Buskermolen wrote:
> On Tuesday 16 January 2007 06:29, Alvaro Herrera wrote:
> > elein wrote:
> > > Have you made any consideration of providing feedback on autovacuum to
> > > users? Right now we don't even know what tables were vacuumed when and
> > > what
28 matches
Mail list logo
