Re: [BUGS] BUG #7685: last_value() not consistent throughout window partition
Sorry for wasting your time, I now see: If frame_end is omitted it defaults to CURRENT ROW. clearly in the documentation. I made the assumption that the default was UNBOUNDED PROCEDING/FOLLOWING which is now very obviously not the case. Again, sorry for not really taking the time to ensure this was in fact a bug. -W On Tue, Nov 20, 2012 at 10:47 AM, Tom Lane wrote: > w...@devauld.ca writes: > > -- The last_value(0 window function appears to be changing values > > -- mid window. An example is detailed below. > > So far as I can see, these results are correct per spec. Note the > caution in the manual about these window functions: > > Note that first_value, last_value, and nth_value consider only the rows > within the "window frame", which by default contains the rows from the > start of the partition through the last peer of the current row. This is > likely to give unhelpful results for last_value and sometimes also > nth_value. You can redefine the frame by adding a suitable frame > specification (RANGE or ROWS) to the OVER clause. See Section 4.2.8 for > more information about frame specifications. > > Since your d1 values are all distinct, the last peer is the same as the > current row, so last_value(v) ends up just producing the current row's v. > Which is what the query is producing. > > If you want the last row in the partition, you could use first_value > with the opposite sort order, or use last_value with the same sort > order and RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING. > (The current SQL committee is nothing if not verbose :-() > > regards, tom lane >
[BUGS] BUG #7686: Provider not configured.
The following bug has been logged on the website: Bug reference: 7686 Logged by: Manoj Email address: bontha.manoj...@tcs.com PostgreSQL version: 9.2.1 Operating system: Windows Description: Dear Team, I have installed PostgreSQL in my system and trying to connect to the database using C# as programming language. But I am get an error that the provider for the PostgreSQL is not registered in the local machine. Trying to connect in using OleDB data provider mode. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6722: Debugger broken?
Hi Could someone provide a short howto about installing debugger for PostgreSQL 9.1 and 9.2? Even a couple of lines would be very helpful. I did not find pldbgapi.sql in the share/contrib folder and the instructions that one finds online appear outdated. Thanks in advance. A. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6722-Debugger-broken-tp5715919p5733070.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6722: Debugger broken?
Here is the two-lines howto for PG 9.2 for Windows. Uncomment and edit postgresql.conf: shared_preload_libraries = '$libdir/plugin_debugger' NB: in 9.2 the plugin_debugger.dll is not in the (non-existing) $libdi/plugins folder. Restart the server. Run CREATE EXTENSION pldbgapi; Cheers, A. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6722-Debugger-broken-tp5715919p5733201.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] w7 vs linux
Is pgsql faster on linux? Currently I've made an installation on W7 and the converted queries are about 3 times slower then on mssql. There's still some optimization to do tho...but the current results don't look to good.
Re: [BUGS] w7 vs linux
Ignore, wrong list... My apologies.. Best, Peter 2012/11/23 Peter Kroon > Is pgsql faster on linux? > Currently I've made an installation on W7 and the converted queries are > about 3 times slower then on mssql. > There's still some optimization to do tho...but the current results don't > look to good. >
Re: [BUGS] Prepared Statement Name Truncation
On 22-11-2012 04:27, Pavel Stehule wrote: > 2012/11/21 Greg Sabino Mullane : Separately, what are > the objections to raising the size limit to 128? > >> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Prepared Statement Name Truncation
2012/11/23 Euler Taveira : > On 22-11-2012 04:27, Pavel Stehule wrote: >> 2012/11/21 Greg Sabino Mullane : Separately, what are >> the objections to raising the size limit to 128? >> >>> significantly larger catalog >> > Less than 5% of catalog columns? I don't buy your argument. default 6201kB (64) updated 6967kB (128) on empty database - so it is 12% more per one database in our warehouses we have more than 10 relations per database and about 1000 databases per warehouse - so these number can be significantly higher second issue can be increasing memory allocations for system caches and some other place Regards Pavel > > > -- >Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ >PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
Euler Taveira writes: > On 22-11-2012 04:27, Pavel Stehule wrote: >>> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and line pointer), so adding 64 bytes would represent 45% bloat. In a database with lots of tables that would be painful. We could avoid this problem if we were prepared to make type "name" be varlena, but that would be rather catastrophic because of the code's habit of overlaying C structures onto catalog rows. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
On 23.11.2012 17:53, Tom Lane wrote: Euler Taveira writes: On 22-11-2012 04:27, Pavel Stehule wrote: significantly larger catalog Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and line pointer), so adding 64 bytes would represent 45% bloat. In a database with lots of tables that would be painful. We could avoid this problem if we were prepared to make type "name" be varlena, ... It would actually be nice to do that because it would *reduce* the amount of space and memory used for the catalogs in the typical case, where the attribute names are much smaller than 64 bytes. I received a complaint just the other day that our backend processes consume a lot of memory, even when idle; the catalog caches are a large part of that. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] Prepared Statement Name Truncation
Heikki Linnakangas writes: > On 23.11.2012 17:53, Tom Lane wrote: >> We could avoid this problem if we were prepared to make type "name" >> be varlena, ... > It would actually be nice to do that because it would *reduce* the > amount of space and memory used for the catalogs in the typical case, Agreed, that would be a nicer place to be ... but the amount of work required to get there is daunting, and rather out of proportion to the benefit IMO. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7683: pg_upgrade missing configuration file
On Tue, Nov 20, 2012 at 11:23:13AM +, bernhard.schra...@innogames.de wrote: > To point this out, postgresql 9.0 and 9.2 are not running, if 9.0 is > running, the 9.0 tests succeed, but afaik they shouldn't running, or at > least 9.2 shouldn't running during upgrade, but without the link to the > config it will never start. The same for 9.0, if it is shut down and the > link is present, it works. I assume this is a "bug" or at least a missing > option for pg_upgrade in addition to debian. Do you confirm? Or do i > undestand something completly wrong? I hope not, thanks in advance Have you seen this in the pg_upgrade 9.2 manual? If you are upgrading a pre-PostgreSQL 9.2 cluster that uses a configuration-file-only directory, you must pass the real data directory location to pg_upgrade, and pass the configuration directory location to the server, e.g. -d /real-data-directory -o '-D /configuration-directory'. -o, --old-options=OPTIONS old cluster options to pass to the server -O, --new-options=OPTIONS new cluster options to pass to the server -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
