2008/12/31 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com 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
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
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
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.
Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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:
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 04:45:01 Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 proper
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
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
On Wed, Dec 31, 2008 at 7:33 AM, Stephen R. van den Berg s...@cuci.nlwrote:
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
Peter Eisentraut pete...@gmx.net 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(); =
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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,
Alvaro Herrera alvhe...@commandprompt.com 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.
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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:
Andreas 'ads' Scherbaum adsm...@wars-nicht.de 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
Hello
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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,
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
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
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
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
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
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Dec 31, 2008 at 01:25:34PM -0500, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/31 Alvaro Herrera alvhe...@commandprompt.com:
Maybe we could have a separate function which returned the info
in various columns (OUT params). Maybe it would be useful to
[ starting to examine this patch now... ]
=?UTF-8?B?QmVuZWRlayBMw6FzemzDsw==?= l...@benedekl.tvnetwork.hu 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
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
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 -
On 31 Dec 2008, at 13:21, Simon Riggs si...@2ndquadrant.com 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
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 original
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 |
Pavel Stehule pavel.steh...@gmail.com 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
Alvaro Herrera alvhe...@commandprompt.com 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 =
On Wed, Dec 31, 2008 at 4:34 PM, Pavel Stehule pavel.steh...@gmail.com 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
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
2008/12/31 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com 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 window specification that
modifies an existing window, not
Pavel Stehule pavel.steh...@gmail.com 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
2008/12/31 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
2008/12/31 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
42 matches
Mail list logo
