2008/12/31 Tom Lane :
> "Pavel Stehule" writes:
>> so I have to modify query to get expected values
>> postgres=# select a, b, last_value(a) over (partition by b),
>> last_value(a) over (partition by b order by a RANGE BETWEEN UNBOUNDED
>> PRECEDING AND UNBOUNDED FOLLOWING) from foo;
>
>> it shou
2008/12/31 Tom Lane :
> "Pavel Stehule" writes:
>> so I have to modify query to get expected values
>> postgres=# select a, b, last_value(a) over (partition by b),
>> last_value(a) over (partition by b order by a RANGE BETWEEN UNBOUNDED
>> PRECEDING AND UNBOUNDED FOLLOWING) from foo;
>
>> it shou
"Pavel Stehule" writes:
> so I have to modify query to get expected values
> postgres=# select a, b, last_value(a) over (partition by b),
> last_value(a) over (partition by b order by a RANGE BETWEEN UNBOUNDED
> PRECEDING AND UNBOUNDED FOLLOWING) from foo;
> it should be noticed in doc?
It is -
"Pavel Stehule" writes:
> wrong
> postgres=# select a, b, sum(a) over (w) from foo window w as
> (partition by b order by a ROWS BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING);
Should be "over w". "over (w)" is a that
modifies an existing window, not just a reference, and in particular
2008/12/31 Tom Lane :
> "Pavel Stehule" writes:
>> I didn't expect so ORDER can change result of function sum.
>
> Read the stuff about window frames. The results you show are
> exactly per spec.
>
I have to do it, when I tested last_value and first_value function I
was surprised more - order by
Andrew Dunstan wrote:
Quite so. CMake outputs MSVC Project files, as I understand it. If you
know of another cross-platform build tool that will do that then speak
up.
I think the wxWidgets team have one, and I think scons has some support
for doing that, though I haven't tried
that part of
On Wed, Dec 31, 2008 at 4:34 PM, Pavel Stehule wrote:
> Hello
>
> I am play with windows function. I was surprised so these queries has
> different results.
>
> postgres=# select sum(a) over (partition by b), a, b from foo;
AFAIUI, this means one sum per b value, the result in the sum column
will
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> On Sunday 21 December 2008 01:48:42 Alvaro Herrera wrote:
>>> ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
>>> ALTER TABLE foo SET (toast.autovacuum_enabled = false);
>>> ALTER TABLE foo TOAST SET (autovacuum_enabled = false);
>>> ALTE
"Pavel Stehule" writes:
> I didn't expect so ORDER can change result of function sum.
Read the stuff about window frames. The results you show are
exactly per spec.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hello
I am play with windows function. I was surprised so these queries has
different results.
postgres=# select sum(a) over (partition by b), a, b from foo;
sum | a | b
-++---
19 | 1 | 1
19 | 1 | 1
19 | 2 | 1
19 | 4 | 1
19 | 2 | 1
19 | 4 | 1
19 | 5 | 1
93 | 11 |
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> --role switch for pg_dump and pg_dumpall: sets the role used while
> dumping, has no effect on the emitted archive.
>
> --role switch for pg_restore: sets the role used while restoring,
> if it's to be different from what -U says.
As one of the origi
On 31 Dec 2008, at 13:21, Simon Riggs wrote:
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
on relations, which would potentially lead to hav
Simon Riggs wrote:
While watching WAL records float by I noticed some AccessExclusiveLocks
occurring unnecessarily during VACUUMs.
This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c
possibly_freeable = vacrelstats->rel_pages -
vacrelstats
Peter Eisentraut wrote:
> On Sunday 21 December 2008 01:48:42 Alvaro Herrera wrote:
> > ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
> > ALTER TABLE foo SET (toast.autovacuum_enabled = false);
> > ALTER TABLE foo TOAST SET (autovacuum_enabled = false);
> > ALTER TABLE foo SET TOAST (auto
[ starting to examine this patch now... ]
=?UTF-8?B?QmVuZWRlayBMw6FzemzDsw==?= writes:
> I also need some feedback about the role support in pg_restore (not
> implemented yet). Currently pg_restore sets the role during the
> restore process according to the TOC entry in the archive. It may also
On Wed, Dec 31, 2008 at 01:25:34PM -0500, Tom Lane wrote:
> "Pavel Stehule" writes:
> > 2008/12/31 Alvaro Herrera :
> >> Maybe we could have a separate function which returned the info
> >> in various columns (OUT params). Maybe it would be useful to
> >> normalize the info as reported the buildf
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Heikki Linnakangas escribi�:
> >> Tom Lane wrote:
> >>> pg_catalog | nth_value | anyelement | anyelement, integer OVER
> >>> window
> >>
> >> That looks like "OVER window" is associated with the "integer
I notice that we allow commands such as
SET TRANSACTION read only read write read only;
BEGIN TRANSACTION read only read only read only;
Unsurprisingly, these violate the SQL Standard:
* p.977 section 19.1 syntax (1)
* p.957 section 17.3 syntax (2)
Not planning on fixing it myself, but others m
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
> http://wiki.postgresql.org/wiki/Hot_Standby
>
> now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link above), with these changes:
* Must ignore_killed_tuples and never kill_prior_tuple during in
"Pavel Stehule" writes:
> 2008/12/31 Alvaro Herrera :
>> Maybe we could have a separate function which returned the info in
>> various columns (OUT params). Maybe it would be useful to normalize the
>> info as reported the buildfarm, which right now is a bit ad-hoc.
> All should be GUC read only
While watching WAL records float by I noticed some AccessExclusiveLocks
occurring unnecessarily during VACUUMs.
This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c
possibly_freeable = vacrelstats->rel_pages -
vacrelstats->nonempty_pages;
if (po
Hello
2008/12/31 Alvaro Herrera :
> Tom Lane wrote:
>> Peter Eisentraut writes:
>> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
>> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>>
>> > Maybe we should separate all that, e.g.,
>>
>> > SELECT version()
"Andreas 'ads' Scherbaum" writes:
> On Sun, 28 Dec 2008 18:19:48 -0500 Tom Lane wrote:
>> If we're going to do this, shouldn't it happen uniformly for *all*
>> ACL displays in describe.c?
> Makes sense, imho.
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing li
On Wednesday 31 December 2008 18:22:50 Bruce Momjian wrote:
> It is true no one asked for this information except Peter (I assume for
> just academic reasons),
no
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Bruce Momjian wrote:
> Tom Lane wrote:
> > I didn't actually see a user request for finding out the pointer width,
> > either, but if there is one then Bruce's proposal seems fine.
>
> It is true no one asked for this information except Peter (I assume for
> just academic reasons),
Huh, count us
Tom Lane wrote:
> Peter Eisentraut writes:
> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>
> > Maybe we should separate all that, e.g.,
>
> > SELECT version(); => 'PostgreSQL 8.4devel'
> > SELECT pg
Alvaro Herrera writes:
> Heikki Linnakangas escribió:
>> Tom Lane wrote:
>>> pg_catalog | nth_value | anyelement | anyelement, integer OVER window
>>
>> That looks like "OVER window" is associated with the "integer", like
>> DEFAULT. I don't have any better suggestions, though.
> pg_ca
Peter Eisentraut writes:
> On Wednesday 31 December 2008 05:50:19 Tom Lane wrote:
>> That was part of the original concept for pg_pltemplate, but IIRC there
>> was push-back from some folks who thought it was a bad idea. Â I don't
>> recall what their arguments were exactly;
> Basically, we have
Tom Lane wrote:
> Peter Eisentraut writes:
> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>
> > Maybe we should separate all that, e.g.,
>
> > SELECT version(); => 'PostgreSQL 8.4devel'
> > SELECT pg
Peter Eisentraut writes:
> On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
>> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> Maybe we should separate all that, e.g.,
> SELECT version(); => 'PostgreSQL 8.4devel'
> SELECT pg_host_os(); => 'bsdi4.3.1'
>
On Wed, Dec 31, 2008 at 7:33 AM, Stephen R. van den Berg wrote:
> The other day I bumped into some ideas about lockfree hashtables.
> Are these of any use in PostgreSQL?
Lock-free and wait-free algorithms have been used in various databases, but
most people tend to shy away from them because of
The other day I bumped into some ideas about lockfree hashtables.
Are these of any use in PostgreSQL?
http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html
http://video.google.com/videoplay?docid=2139967204534450862
--
Sincerely,
Stephen R. van den Berg.
"I hate spinach, and
Heikki Linnakangas escribió:
> Tom Lane wrote:
>> I am not thrilled about inventing a new column for this, but how about
>> a display like so:
>>
>> regression=# \df nth_value
>> List of functions
>>Schema | Name| Result data type | Argument data types
>>
On Wednesday 31 December 2008 05:50:19 Tom Lane wrote:
> That was part of the original concept for pg_pltemplate, but IIRC there
> was push-back from some folks who thought it was a bad idea. I don't
> recall what their arguments were exactly;
Basically, we have no information about what the prop
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > ... Moreover, there does not actually seem to be a
> > > way to find out whether you have a 32-bit or a 64-bit build (except by
> > > using OS tools).
> >
> > I think the basic definit
Tom Lane wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
+---+--+-
Laurent Coustet wrote:
> Andrew Dunstan wrote:
>>
>> Attached is the latest parallel restore patch. I think this is getting
>> fairly close.
>
> Just some details, you often mix tab and spaces for indentation...
> What's the standard in pgsql ?
It's tabs, see:
http://www.postgresql.org/docs/8.3/s
Bruce Momjian wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>>> ... Moreover, there does not actually seem to be a
>>> way to find out whether you have a 32-bit or a 64-bit build (except by
>>> using OS tools).
>> I think the basic definition of "32 bit" or "64 bit", certainly for
>> our
On Tue, 2008-12-30 at 18:31 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > (a) always ignore LP_DEAD flags we see when reading index during
> > recovery.
>
> This sounds simplest, and it's nice to not clear the flags for the
> benefit of transactions running after the recovery is done
Andrew Dunstan wrote:
Attached is the latest parallel restore patch. I think this is getting
fairly close.
Just some details, you often mix tab and spaces for indentation...
What's the standard in pgsql ?
--
Laurent COUSTET
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Mon, 2008-12-29 at 18:13 -0600, Kevin Grittner wrote:
> I hope someone can show me something good I've missed so far.
You're viewing this in problem-exposed language, unintentionally I'm
sure. My viewpoint on this is that database concurrency is a big issue,
but that the way we do things roun
2008/12/31 Tom Lane :
> "Robert Haas" writes:
>>> Apparently that analogy didn't impress anyone but me.
>
>> It impressed me. I liked making WINDOW a flag that occurs later in
>> the statement a lot better.
>
> I ended up going with the flag/attribute approach. The other would be
> only marginal
42 matches
Mail list logo
