[GENERAL] Ubuntu/Debian PGDP

In a fresh new install of PostgreSQL 9.5.2 on Ubuntu 16.04 I am getting this: ... Setting up postgresql-9.5 (9.5.2-1.pgdg16.04+1) ... Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/(?http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Make for PgSQL?

mation about dependencies. I've been playing with the GNU Make itself but it's quite hard to keep track of changes and to re-load a single SQL file that changed. Is there any hint about "best prectices", software tools and the likes? Many thanks to you all. -- Vincenzo

[GENERAL] stable functions

Hi all. Can functions whose effect is to create functions (yep!) be labelled as "stable"? Thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(e

Re: [GENERAL] stable functions

On Thursday 31 May 2007 13:23:36 Filip Rembiałkowski wrote: > 2007/5/31, Vincenzo Romano <[EMAIL PROTECTED]>: > > Hi all. > > > > Can functions whose effect is to create functions (yep!) > > be labelled as "stable"? > > According to the docs, n

Re: [GENERAL] Make for PgSQL?

hat are in that file, possibly cascading; 2. drop all objects into files that require the modified one; 3. reload everything that needs reloading. All automagically. I'll try it right now. On Thursday 31 May 2007 15:43:55 Reece Hart wrote: > On Thu, 2007-05-31 at 09:01 +0200, Vincenzo Ro

[GENERAL] Numeric performances

into data storage evaluations. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/

Re: [GENERAL] Numeric performances

On Thursday 31 May 2007 19:42:20 Alvaro Herrera wrote: > It is. But why do you care? You either have the correctness that > NUMERIC gives, or you don't. Because FLOAT8 can be precise enough for some application and not enough for other ones. -- Vincenzo Romano -- Maybe Computer

Re: [GENERAL] Numeric performances

E INDEX test_b ON test(b); > CREATE INDEX test_f ON test(f); CREATE INDEX test_n ON test(n); ROLLBACK; > CREATE INDEX > Temps : 102,901 ms > CREATE INDEX > Temps : 123,406 ms > CREATE INDEX > Temps : 105,255 ms > CREATE INDEX > Temps : 134,468 ms -- Vincenzo Romano -

Re: [GENERAL] Numeric performances

mps : 46,589 ms > >> forum_bench=> SELECT sum(f) FROM test; > >> Temps : 63,865 ms > >> > >> forum_bench=> SELECT sum(b) FROM test; > >> Temps : 157,018 ms > >> forum_bench=> SELECT sum(n) FROM test; > >> Temps : 124,816 ms --

[GENERAL] Running v8.1 amd v8.2 at the same time for a transition

t? Thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to

Re: [GENERAL] Running v8.1 amd v8.2 at the same time for a transition

On Tuesday 05 June 2007 23:55:20 Oliver Elphick wrote: > On Tue, 2007-06-05 at 23:40 +0200, Vincenzo Romano wrote: > > Hi all. > > I need to run both 8.1 and 8.2 at the same time in order to check > > everything in 8.2 *before* shutting 8.1 down. > > I need to run both

Re: [GENERAL] Running v8.1 amd v8.2 at the same time for a transition

entation. The actual fault was mine plus a lack into the manpages. The mechanism could be complicated, but if the needed documentation is up to date and complete, I suspect that a number of people can live with it. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Human

Re: [GENERAL] Running v8.1 amd v8.2 at the same time for a transition

personally missed this last point!) But I would have preferred to see an additional paragraph in the standard tools man pages (psql/pg_dump/pg_restore) talking about clusters, pointing to that file and possibly cross referencing to pg_lsclusters. -- Vincenzo Romano -- Maybe Computer will never bec

[GENERAL] Wider than float8

, is there any way to use those "long doubles" in SQL? Many thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(end of broadcast)--- TIP 3: H

[GENERAL] INSERT ... RETURNING in v8.2

; Well, at least on v8.2.4 I cannot return count(*), that is the number of lines actually inserted into the table. Nor I can return any aggregate function of them. Am I doing anything wrong or is there some missing sentence in the documentation? -- Vincenzo Romano -- Maybe Computer will never b

Re: [GENERAL] INSERT ... RETURNING in v8.2

On Tuesday 12 June 2007 16:35:05 Martijn van Oosterhout wrote: > On Tue, Jun 12, 2007 at 04:18:32PM +0200, Vincenzo Romano wrote: > > Well, at least on v8.2.4 I cannot return count(*), that is the > > number of lines actually inserted into the table. Nor I can > > return any

Re: [GENERAL] INSERT ... RETURNING in v8.2

On Tuesday 12 June 2007 18:26:35 Tom Lane wrote: > Vincenzo Romano <[EMAIL PROTECTED]> writes: > > Second, I'm not using nested statements, but rather a plain > > INSERT ... RETURNING COUNT(*) INTO var (it's inside a PL/PgSQL > > function body). It should

[GENERAL] PGSQL development tools. Any advice?

tter tool to be run under Linux/KDE? MTIA! -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

[GENERAL] Using the query INTERSECTion

d AND dynamic_cond; I could use: SELECT * FROM joinedtables WHERE static_cond INTERSECT SELECT * FROM joinedtables WHERE dynamic_cond I'm wondering what'd be the difference in efficiency between these two queries. Is there any advise? Many thanks in advance. -- Vincenzo Romano -- Mayb

Re: [GENERAL] Using the query INTERSECTion

On Monday 18 June 2007 19:27:35 Martijn van Oosterhout wrote: > On Mon, Jun 18, 2007 at 04:10:41PM +0200, Vincenzo Romano wrote: > > Hello everyone. > > > > In order to build some dynamic queries (EXECUTE under PL/PgSQL) > > I'm taking in consideration to use the IN

[GENERAL] [PGSQL 8.2.x] INSERT+INSERT

ive is to create an SQL script to load some 20+ million records and avoiding function calls would save some time. Thanks in advance. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(en

Re: [GENERAL] [PGSQL 8.2.x] INSERT+INSERT

On Thursday 21 June 2007 15:47:17 Dawid Kuroczko wrote: > On 6/21/07, Vincenzo Romano <[EMAIL PROTECTED]> wrote: > > Hi all. > > I'd like to do the following: > > > > insert into t1 > > values ( > > 'atextvalue',(

[GENERAL] Function call costs for SQL and PLPgSQL

I've been told that SQL function bodies get "inlined" during execution. Is thus correct to consider SQL functions "faster" that the conterpart written in PLPgSQL? Thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they wo

[GENERAL] Error or bug?

able1 type. I suspect this could be a bug. But cannot be sure. Any hint? -- Vincenzo Romano -= NotOrAnd.IT Information Technologies =- tel +39 0823 454163 | cel +39 339 8083886 | fax +39 02 700506964 ---(end of broadcast)--- TIP 3: Have you c

[GENERAL] Execution variability

ibe reasons for slow down. No luck in this. Do you have any hint? -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1988] ---(end of broadcast)--- TIP 5: don'

Re: [GENERAL] Execution variability

On Wednesday 27 June 2007 23:46:25 Vincenzo Romano wrote: > Hi all. > I understand this can be a ridiculous question for most you. > > The very same query on the very same db shows very variable > timings. I'm the only one client on an unpupolated server so I'd > exp

Re: [GENERAL] Execution variability

On Thursday 28 June 2007 12:00:40 Richard Huxton wrote: > Vincenzo Romano wrote: > > On Wednesday 27 June 2007 23:46:25 Vincenzo Romano wrote: > >> Hi all. > >> I understand this can be a ridiculous question for most you. > >> > >> The very same

Re: [GENERAL] Execution variability

e time. I thank you very much for your attention and help. On Thursday 28 June 2007 13:17:54 Richard Huxton wrote: > Vincenzo Romano wrote: > >>>> The very same query on the very same db shows very variable > >>>> timings. I'm the only one client on an unpupo

Re: [GENERAL] Execution variability

On Thursday 28 June 2007 16:08:06 Alvaro Herrera wrote: > Vincenzo Romano escribió: > > The values are here below. I suppose that the "hashed" > > ones imply a default value. > > Correct (widely known as "commented out") > > > By the way, it

[GENERAL] Execution variability

ibe reasons for slow down. No luck in this. Do you have any hint? -- Vincenzo Romano -= NotOrAnd.IT Information Technologies =- tel +39 0823 454163 | cel +39 339 8083886 | fax +39 02 700506964 ---(end of broadcast)--- TIP 3: Have you check

[GENERAL] Weird error message in SQL function call

COMMIT command either in the function itself or in any other function called by f_relazione(). In the syslog I see that this is labelled as error #0A000 "Feature not supported". Is there any hint? -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For su

Re: [GENERAL] Weird error message in SQL function call

On Monday 16 July 2007 12:18:23 Richard Huxton wrote: > Vincenzo Romano wrote: > > Hi all. > > > > I've got this error message while running an SQL function: > > > > BEGIN > > psql:filtb.sql:1029: ERROR: COMMIT is not allowed in a SQL > > fu

[GENERAL] Weird error message in SQL function call

COMMIT command either in the function itself or in any other function called by f_relazione(). In the syslog I see that this is labelled as error #0A000 "Feature not supported". Is there any hint? -- Vincenzo Romano -= NotOrAnd.IT Information Technologies =- tel +39 0823 454163

[GENERAL] Difference between PRIMARY KEY index and UNIQUE-NOT NULL index

n the very same order. The query has not been modified. In the older case, thanks to the EXPLAIN command, I saw that the join was causing a sort on the index elements, while the primary key was not. So ther's some difference for sure, but I'm missing it. Any hint? -- Vincenzo Romano --

[GENERAL] Difference between PRIMARY KEY index and UNIQUE-NOT NULL index

n the very same order. The query has not been modified. In the older case, thanks to the EXPLAIN command, I saw that the join was causing a sort on the index elements, while the primary key was not. So ther's some difference for sure, but I'm missing it. Any hint? -- Vincenzo Romano

Re: [GENERAL] Difference between PRIMARY KEY index and UNIQUE-NOT NULL index

t deeper analisys. In the original setup, the "UNIQUE" constraint had been dropped *before* doing the tests. So the "slow" case is without the UNIQUE constraint but with an index. The NOT NULL was instead there. What I don't understand is why the planner in order to accom

Re: [GENERAL] Difference between PRIMARY KEY index and UNIQUE-NOT NULL index

On Sunday 22 July 2007 19:20:08 Tom Lane wrote: > Vincenzo Romano <[EMAIL PROTECTED]> writes: > > In the original setup, the "UNIQUE" constraint had been dropped > > *before* doing the tests. So the "slow" case is without the > > UNIQUE constra

[GENERAL] SQL function and "UPDATE...RETURNING"

update stetement won't return values. I also understand that by switching to PLPGSQL I would b able to do write the function. But I'd prefer SQL in this case. -- Vincenzo Romano -- Maybe Computer will never become as intelligent as Humans. For sure they won't ever become so s

[GENERAL] How to avoid "Seq Scans"?

(cost=958786.20..970734.55 rows=4779338 width=28) Sort Key: f2,f3 -> Seq Scan on t (cost=0.00..85501.38 rows=4779338 width=28) I'd like to know a hint about a technicque to avoid the sequential scan! Thanks. -- Vincenzo Romano -- Maybe Computer will never become as intelligent a

Re: [GENERAL] How to avoid "Seq Scans"?

On Wednesday 29 August 2007 11:20:53 Richard Huxton wrote: > Vincenzo Romano wrote: > > Hi all. > > > > In PG 8.2.4 I have a 4+M rows table like this: > > > > I'd need to write a stored function that should do the > > following: > >

[GENERAL] Anomalia file FILBD.TXT

Buon giorno. Nel file FILBD.TXT sono presenti dei prodotti per il quali il campo "Unita' di Misura" (offset 182) presenza il valore "PM". Allego la lista dei prodotti interessati. -- Vincenzo Romano NotOrAnd.IT Information Technologies cel. +39 339 8083886 tel. +3

Re: [GENERAL] Anomalia file FILBD.TXT

Il Friday 14 December 2007 19:32:14 Andrej Ricnik-Bay ha scritto: > On 12/15/07, Vincenzo Romano <[EMAIL PROTECTED]> wrote: > > Buon giorno. > > Nel file FILBD.TXT sono presenti dei prodotti per il quali il campo > > "Unita' di Misura" (offset 182) presen

[GENERAL] Hints for trees

, would it make any sense (and why) to use wither GIN or GiST indexing? I'll appreciate also any link to documentation or discussions about this topic. Thanks. -- Vincenzo Romano at NotOrAnd Information Technologies Software Hardware Networking Training Support Security -- NON QVIETIS M

[GENERAL] PL/PgSQL and pg_temp pseudo-schema

PL/PgSQL doesn't know the pg_temp meta schema in case you need to really work on that TEMP TABLE. At the moment I had to move those DDL/DML queries within a "plain" SQL function. Is this a feature or a bug? (Seriously, I mean! :-) TIA. -- Vincenzo Romano - NotOrAnd.IT Informati

[GENERAL]

;s a moment when the full table doesn't exist. Would a transaction enclosure ensure that the table F will be always available to all clients? Thanks. -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-g

Re: [GENERAL] transactional swap of tables

> Vincenzo Romano wrote: > >> I'd like to "replace" a full table F with an empty one E. >> In order to do this I see only one way: >> >> ALTER TABLE F RENAME TO T; >> ALTER TABLE E RENAME TO F; >> ALTER TABLE T RENAME TO E; -- optiona

Re: [GENERAL] Update big table

2013/7/14 Haiming Zhang : > Hi All, > > > > I am using postgres 9.1, I have a question about updating big table. Here is > the basic information of this table. > > 1. This table has one primary key and other 11 columns. > > 2. It also has a trigger that before updat

Re: [GENERAL]

2013/7/14 Luca Ferrari : > On Fri, Jul 12, 2013 at 1:23 PM, Vincenzo Romano > wrote: >> Hi all >> I'm making some experiments with table archiving and I'd like to >> "replace" a full table F with an empty one E. >> In order to do this I see only

Re: [GENERAL]

2013/7/15 Luca Ferrari : > On Sun, Jul 14, 2013 at 8:36 PM, Vincenzo Romano > wrote: > >> I am only concerned about how late is done the binding between a table >> name and the actual OID for other functions, views and triggers. > > > Well, it should work like this:

Re: [GENERAL]

2013/7/15 Luca Ferrari : > On Mon, Jul 15, 2013 at 8:33 AM, Vincenzo Romano > wrote: > >> The alternative is to do things the "good ol' way" by DELETING+INSERTING >> (http://tapoueh.org/blog/2013/07/05-archiving-data-fast.html) >> Where I'd fear for

Re: [GENERAL] transactional swap of tables

I have done the following test pn v9.2.4 with two concurrent sessions: -- session no.1 tmp1=# create table t1 ( t text ); CREATE TABLE Tempo: 37,351 ms tmp1=# create table t2 ( t text ); CREATE TABLE Tempo: 33,363 ms tmp1=# create or replace function f1( out tx text ) tmp1-# language plpgsql tmp1-

Re: [GENERAL] pgAdmin for ubuntu

2013/7/17 Muhammad Bashir Al-Noimi : > Howdy, > > After upgrading my Pg from 9.1 to 9.2 the avaliable pgAdmin in ubuntu > 21.10 reporotiy can't deal with Pg 9.2. > > How can I get recent pgAdmin version for ubuntu 12.10? > > P.S. > - I tried ppa:pitti/postgresql but it doesn’t contain on suitable >

Re: [GENERAL] pgAdmin for ubuntu

2013/7/17 Muhammad Bashir Al-Noimi : > On Wed, Jul 17, 2013 at 3:34 PM, Vincenzo Romano > wrote: >> Once you "sudo add-apt-repository ppa:pitti/postgresql" then you go in >> /etc/apt/sources.list.d/pitti* and you replace the word with your >> Ubuntu version

Re: [GENERAL] Why are stored procedures looked on so negatively?

2013/7/24 Aaron Abreu : > a NON-technical version... > > st.procedures and automation are great... > > but... > sounds like everybody is dancing around the main theme.. > so lets say it > that dreaded word that developers and DBA's cring to hear... > the one part of our job that we all hate...

Re: [GENERAL] Why are stored procedures looked on so negatively?

2013/7/24 Aaron Abreu : > a NON-technical version... > > st.procedures and automation are great... > > but... > sounds like everybody is dancing around the main theme.. > so lets say it > that dreaded word that developers and DBA's cring to hear... > the one part of our job that we all hate...

Re: [GENERAL] Why are stored procedures looked on so negatively?

2013/7/25 Luca Ferrari : > On Thu, Jul 25, 2013 at 2:57 AM, Some Developer > wrote: >> The added advantage of removing load from the app servers so they can >> actually deal with serving the app is a bonus. > > Uhm...I don't know what application you are developing, but I don't > buy your explaina

[GENERAL] RETURNS SETOF RECORD with 1 column

TEXT", but why forcing me to "deviate" from a very general construct for a 1 column case? Is this a bug/enhancement or am I missing something? TALIA! -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general ma

Re: [GENERAL] RETURNS SETOF RECORD with 1 column

2017-07-27 16:03 GMT+02:00 Tom Lane : Thanks a lot for your reply with valuable details. > Vincenzo Romano writes: >> CREATE OR REPLACE FUNCTION afun1( OUT ot TEXT ) >> RETURNS SETOF RECORD > >> The error message for afun1() reads: >> ERROR: function result ty

Re: [GENERAL] RETURNS SETOF RECORD with 1 column

2017-07-28 8:36 GMT+02:00 David G. Johnston : > On Thursday, July 27, 2017, David G. Johnston > wrote: >> >> On Thursday, July 27, 2017, Vincenzo Romano >> wrote: >>> >>> The main difference is that with RETURNS SETOF RECORD I still get the >>&

Re: [GENERAL] RETURNS SETOF RECORD with 1 column

Il 28 lug 2017 16:18, "Tom Lane" ha scritto: Vincenzo Romano writes: > I would like to understand the typo protection mentioned by Tom earlier: > I need to understand the reason for creating that special case. Well, case A: create function foo(out x int4) returns setof int

Re: [GENERAL] Results interpretation

Afaik, pgresult structure and it's fields are not meant to be handled directly apart of comparing the pointer to null. -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS Il 18 ago 2017 19:46, "Igor Korot" ha scritto: > Hi,

Re: [GENERAL] Results interpretation

What I can tell you is not more of what is in the documentation. https://www.postgresql.org/docs/9.6/static/libpq-exec. html#LIBPQ-EXEC-SELECT-INFO In particular see the function PQBinaryTuples. -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS Il

Re: [GENERAL] Results interpretation

Il 18 ago 2017 21:08, "Igor Korot" ha scritto: Hi, Vincenzo, On Fri, Aug 18, 2017 at 2:52 PM, Vincenzo Romano wrote: > What I can tell you is not more of what is in the documentation. > > https://www.postgresql.org/docs/9.6/static/libpq-exec. html#LIBPQ-EXEC-SELECT-INFO >

Re: [GENERAL] Results interpretation

Il 18 ago 2017 21:59, "Vincenzo Romano" ha scritto: Il 18 ago 2017 21:08, "Igor Korot" ha scritto: Hi, Vincenzo, On Fri, Aug 18, 2017 at 2:52 PM, Vincenzo Romano wrote: > What I can tell you is not more of what is in the documentation. > > https://www.postgre

Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?

.. is OK. CREATE TABLE pg_temp.tablename ... is OK. DROP TABLE pg_temp.tablename ... is OK. DROP TEMP TABLE tablename ... is NOT OK. Unless the standard explicitly forbids it, why not supporting both syntaxes in all commands using the TABLE predicate? Those are semantically equivalent. Aren't they

Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?

2017-08-24 11:04 GMT+02:00 Pavel Stehule : > > > 2017-08-24 9:11 GMT+02:00 Vincenzo Romano : >> >> 2017-08-24 3:08 GMT+02:00 Tom Lane : >> > "David G. Johnston" writes: >> >> I'm wondering if there is anything technical preventing someon

Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?

2017-08-24 12:06 GMT+02:00 Pavel Stehule : > > > 2017-08-24 11:46 GMT+02:00 Vincenzo Romano : >> >> 2017-08-24 11:04 GMT+02:00 Pavel Stehule : >> > >> > >> > 2017-08-24 9:11 GMT+02:00 Vincenzo Romano : >> >> >> >>

Re: [GENERAL] Numeric numbers

Quoting from documentation: "without any precision or scale [you get] a column in which values of any precision and scale can be stored, up to the implementation limit on precision." I suspect the cast is doing some precision limitation. -- Vincenzo Romano - NotOrAnd.IT Information Te

Re: [GENERAL] Numeric numbers

a precision of numeric(100,90), which means 90 > decimals and that is exactly what you got!* > > *The result is correct, so what is your question?* > > -- > *Melvin Davidson* > I reserve the right to fantasize. Whether or not you > wish to share my fantasy is entirely up to you. > The original snippet reads: select 1::numeric/3; And I think Francisco is asking why only 20 digits. -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS

[GENERAL] Inheritance efficiency

xes? Will these answers change in v9? -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Inheritance efficiency

2010/4/26 Bruce Momjian : > Vincenzo Romano wrote: >> Hi all. >> >> I'm wondering how efficient the inheritance can be. >> I'm using the constraint exclusion feature and for each child table >> (maybe but one) I have a proper CHECK constraint. >> H

Re: [GENERAL] PostgreSQL Performance issue

2010/4/27 Greg Smith : > a.bhattacha...@sungard.com wrote: >> >> I have *622,000 number of records *but it is taking almost *4 and half >> hours* to load these data into the tables. Without the schema and the queries, all you can get is guessing. -- Vincenzo Romano

Re: [GENERAL] Notification of Limited Account Access

response due to some email forwarding ... Anyway, don't follow those directions if you are not involved into that domain! -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

Re: [GENERAL] Inheritance efficiency

2010/4/26 Vincenzo Romano : > 2010/4/26 Bruce Momjian : >> Vincenzo Romano wrote: >>> Hi all. >>> >>> I'm wondering how efficient the inheritance can be. >>> I'm using the constraint exclusion feature and for each child table >>> (ma

Re: [GENERAL] Inheritance efficiency

2010/4/30 David Fetter : > On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote: >> > No info about this point (partial indexes)? >> > Is also this geared with linear algorithms ? >> >> Should I move to an "enterprise grade" version of Post

Re: [GENERAL] Inheritance efficiency

2010/4/30 Vincenzo Romano : > 2010/4/30 David Fetter : >> On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote: >>> > No info about this point (partial indexes)? >>> > Is also this geared with linear algorithms ? >>> >>> Should I

Re: [GENERAL] Nuevo sobre PGday Latinoamericano 2011...

s Ciencias Informáticas.Ciudad de la Habana. Cuba. > «"Se tu el cambio que quieres ver en el mundo"..."El éxito es el fracaso > superado por la perseverancia"» pgsql-general@postgresql.org, pgsql-annou...@postgresql.org are english language lists. So Spanish is not really

Re: [GENERAL] Inheritance efficiency

2010/4/30 Alvaro Herrera : > Vincenzo Romano wrote: > >> In this specific case, if you think about "inheritance for >> partitioning" and you stick with the example idea of "one partition >> per month", then the current solution is more than OK. >>

Re: [GENERAL] Inheritance efficiency

2010/5/1 Greg Smith : > Vincenzo Romano wrote: >> >> I argued that O(n) stuff will keep it away from "enterprise grade" >> applications. >> I've been told earlier that "It is fine for dozens of child tables, >> but not thousands; >>

Re: [GENERAL] Inheritance efficiency

2010/5/1 Greg Smith : > Vincenzo Romano wrote: >> >> While I can agree that "Enterprise grade" is a buzzword, it does mean >> something: "very large amount of data" among other. >> > > http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug

Re: [GENERAL] Latest source RPMs for 8.1.20

patch files. > > Thanks. Just curiosity: why are you using 8.1? -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Latest source RPMs for 8.1.20

2010/5/3 Vincenzo Romano : > 2010/5/3 Justin Pasher : >> - Original Message - >>> >>> From: Vincenzo Romano >>> Date: Mon, 3 May 2010 17:59:10 +0200 >>> Subject: Re: Latest source RPMs for 8.1.20 >>> To: Justin Pasher >>>

Re: [GENERAL] Latest source RPMs for 8.1.20

2010/5/3 Justin Pasher : > - Original Message - >> >> From: Vincenzo Romano >> Date: Mon, 3 May 2010 17:59:10 +0200 >> Subject: Re: Latest source RPMs for 8.1.20 >> To: Justin Pasher >> CC: pgsql-general@postgresql.org >> >> 2010/5/3 Ju

[GENERAL] (psuedo) random serial for PK or at least UNIQUE NOT NULL?

Hi all. I'm willing to change an BIGINT ID column (actually a SERIAL8) with a BIGINT whose valules are (pseudo)random. The main objective is to avoid guessability. I whish I could also use it as the PK (as it's now) but that's not really important now. Any hint? -- Vincenzo

Re: [GENERAL] (psuedo) random serial for PK or at least UNIQUE NOT NULL?

2010/5/4 Alvaro Herrera : > Vincenzo Romano wrote: >> Hi all. >> >> I'm willing to change an BIGINT ID column (actually a SERIAL8) with a >> BIGINT whose valules are (pseudo)random. >> The main objective is to avoid guessability. >> I whish I could al

Re: [GENERAL] (psuedo) random serial for PK or at least UNIQUE NOT NULL?

; Hum, not sure. If I understand correctly, you won't be able to get the > original int64 from the generated one. Why should I bother? > Better rewrite the function for 2^64 isn't it ? Sure!. -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS

[GENERAL] R: index or not

It strongly depends from the queries. Usually yes Il giorno 2010 5 15 16:20, "Armand Turpel" ha scritto: Hi, Does it make sense to create indexes on a table which only contains bigint fields? Is there any performance gain? Example: Table x_rel id_a bigint id_b bigint id_c bigint id_d bigint T

[GENERAL] Inheritance efficiency

Hi all. I'd like to know how efficient is inheritance when the number of children gets higher and higher. I mean both with and without the constraint exclusion. Will this change with 9.0 or possibly 9.1? Thanks. -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS

[GENERAL] [WISHLIST] EXECUTE SPRINTF

E itself with something like "EXECUTE SPRINTF ". Does this make any sense to you all? -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Converting BYTEA from/to BIGINT

Hi all. I'd like to convert an 8-bytes BYTEA into a BIGINT and possibly vice versa. Is there any way to do it? -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to

Re: [GENERAL] Converting BYTEA from/to BIGINT

2010/7/26 Vincenzo Romano : > Hi all. > > I'd like to convert an 8-bytes BYTEA into a BIGINT and possibly vice versa. > Is there any way to do it? Something like: CREATE OR REPLACE FUNCTION bytea_to_int8( ba BYTEA, OUT res INT8 ) LANGUAGE plpgsql STRICT AS $BODY$ DECLARE i

Re: [GENERAL] Converting BYTEA from/to BIGINT

2010/7/26 Pavel Stehule : > Hello > > you can try > > postgres=# select int8send(256); >      int8send > >  \x0100 > (1 row) > > for converting from bytea to int8 you need a custom function - probably in C > :( int8send? --

[GENERAL] Re: What to do if space for database decrease and no additional hard drive is possible?

(performance and reliability) is more important by far ... -- Vincenzo Romano NotOrAnd Information Technologies NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: What to do if space for database decrease and no additional hard drive is possible?

2010/7/26 A. Kretschmer : > In response to Vincenzo Romano : >> 2010/7/26 A. Kretschmer : >> > In response to Ivan Voras : >> >> * buy external storage (NAS, or even an external USB drive), move the >> >> database to it >> > >> > buy ex

Re: [GENERAL] sql dump

x27;s a longer backstory here that I'm happy to explain if > necessary.)  I'm looking for an efficient way to dump all the data in the DB > without having to SELECT * on each table. > > Thanks in advance! > Scott You can use COPY but you won't easily have the DD

Re: [GENERAL] Converting BYTEA from/to BIGINT

2010/7/26 Vincenzo Romano : > 2010/7/26 Pavel Stehule : >> Hello >> >> you can try >> >> postgres=# select int8send(256); >>      int8send >> >>  \x0100 >> (1 row) >> >> for con

Re: [GENERAL] Converting BYTEA from/to BIGINT

2010/7/27 Dimitri Fontaine : > Vincenzo Romano writes: >> Now, why doing this? >> I am using a plain SEQUENCE to create a (kind of) "session ID". That >> is simple but predictable. >> The idea is to use this function in conjunction with encrypt (from >>

Re: [GENERAL] Comparison of Oracle and PostgreSQL full text search

a training (and costs), as if people would remain there forever and knowledge is a definitive thing! THe point would be to put costs in a time perspective, that is, how much would it cost in, say, 5 years, with PG and the same for Oracle. -- Vincenzo Romano NotOrAnd Information Technologies NON

Re: [GENERAL] How Big is Too Big for Tables?

t near > Access'  two gigabyte database size limit, I'm a little nervous of these > much bigger files. So I'd appreciate anyone's advice here. > AFAIK it could be just a matter of how much RAM do you have, DDL and DML (aka queries). Hitting the real PG limits it'

Re: [GENERAL] How Big is Too Big for Tables?

first level *and* by day (28,29,30 or 31) on the second one) would do the magics, but here the DDL would be quite killing, even with some PL/PGSQL helper function. The "linearity" of the index selection killed the performances also in the "really lots of partial indexes&qu

  1   2   >