Re: [GENERAL] looking for a faster way to do that

You forgot to include the list ;) On 26 Sep 2011, at 6:06, haman...@t-online.de wrote: > Alban Hertroys wrote: >>> >>> To me it sounds a little bit like you're comparing every item in a = >>> warehouse to a set of descriptions to see what type of item it is, which = >>> is something you would be

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On 9/26/11, Uwe Schroeder wrote: > In my experience "data formatting" goes both ways, in and out. Out is > obviously not a major issue because errors don't cause data corruption. In, > however, is a different issue. Errors in "inwards" conversion will cause > data > corruption. So unless you have

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On 9/25/11, Karsten Hilbert wrote: > On Sun, Sep 25, 2011 at 09:41:19PM +, Albretch Mueller wrote: > >> I am amazed to read that you/the PC community were still running >> regression tests >> >> *in ASCII*: >> >> http://www.postgresql.org/docs/9.1/static/release-9-1.html (E.1.3.12. >> Sourc

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On 09/25/11 7:48 PM, Uwe Schroeder wrote: Which still depends on your use case. Your assumption is that every piece of code is coded in Java - which is fine if that's what your application calls for. It's going to be a major hassle when you ever have to re-code in a different language though. i

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

> First, I wonder what kind of technical person would say there are > "de-facto truth(s)". I thought only politicians would talk like that. Well, politicians and Microsoft, Oracle etc. :-) > Now, in a sense you are right, I am talking from the background of my > own experiences (and so are you

Re: [GENERAL] New feature: accumulative functions.

I write small summary. Feature details: additional flags for monotonical functions. Learn planner to use them. New node in execution plan - functional index scan. Pro: single btree index may be used in many expressions containing only monotonnical functions. Contra: big developement effort. No n

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On Sun, Sep 25, 2011 at 09:41:19PM +, Albretch Mueller wrote: > I am amazed to read that you/the PC community were still running regression > tests > > *in ASCII*: > > http://www.postgresql.org/docs/9.1/static/release-9-1.html (E.1.3.12. Source > Code) > * Run regression tests > (postgr

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On 9/25/11, David Johnston wrote: > On Sep 25, 2011, at 2:11, Albretch Mueller wrote: >> Can you or do you know of anyone who has made those kinds of >> imaginations falsifiable? > > No; not worth my effort. ~ ;-) ~ >>> That approach strips down on application complexity. My apps don't have >>>

Re: [GENERAL] In which case PG_VERSION file updates ?

On Sun, Sep 25, 2011 at 3:26 AM, Raghavendra wrote: > Thanks Adrian Klaver, > Provided link gives about the information of what PG_VERSION file, which am > aware of:) > In my observation, all the object related OID's, _fsm, _vm files under > $PGDATA/base/database-oid/ directory will change as per

Re: [GENERAL] New feature: accumulative functions.

For single argument strict increasing function f(x), estimation is simple: it is f(estimation of x). 2011/9/25, Pavel Stehule : > 2011/9/25 pasman pasmański : >> See that setting flag on function need less work than create new gist >> operator. Of course if postgresql's developers do biggest work

Re: [GENERAL] In which case PG_VERSION file updates ?

On Sunday, September 25, 2011 2:26:56 am Raghavendra wrote: > Thanks Adrian Klaver, > > Provided link gives about the information of what PG_VERSION file, which am > aware of:) > > In my observation, all the object related OID's, _fsm, _vm files under > $PGDATA/base/database-oid/ directory will c

Re: [GENERAL] New feature: accumulative functions.

2011/9/25 pasman pasmański : > See that setting flag on function need less work than create new gist > operator. Of course if postgresql's developers do biggest work before. any feature in pg should to have a general usage - with real use cases and real performance advantages. I am not sure, if m

Re: [GENERAL] New feature: accumulative functions.

Yes, i wrote this for pleasure and discusion, not for solve a real problem :). 2011/9/25, Tom Lane : > =?ISO-8859-2?Q?pasman_pasma=F1ski?= writes: >> I found second use case. Look at expression: >> where left(str,n)='value' > >> function left(str,n) increase monotonically for str and n. With this

Re: [GENERAL] New feature: accumulative functions.

See that setting flag on function need less work than create new gist operator. Of course if postgresql's developers do biggest work before. 2011/9/25, Pavel Stehule : > 2011/9/25 pasman pasmański : >> I found second use case. Look at expression: >> >> where left(str,n)='value' >> >> function lef

Re: [GENERAL] New feature: accumulative functions.

=?ISO-8859-2?Q?pasman_pasma=F1ski?= writes: > I found second use case. Look at expression: > where left(str,n)='value' > function left(str,n) increase monotonically for str and n. With this > feature it can use index on str. Can't get excited about that, because that only works in C locale, and

Re: [GENERAL] New feature: accumulative functions.

This feature give profits for increasing muliti-arg functions. Example: WHERE f(x,param) = const it may be impossible to create functional indexes for all params. 2011/9/25, Pavel Stehule : > Hello > > what is a real use case? > > Regards > > Pavel > > 2011/9/25 pasman pasmański : >> My englis

Re: [GENERAL] New feature: accumulative functions.

2011/9/25 pasman pasmański : > I found second use case. Look at expression: > > where left(str,n)='value' > > function left(str,n) increase monotonically for str and n. With this > feature it can use index on str. > > Classic index needs recreating. > these use cases are just theory - for example

Re: [GENERAL] New feature: accumulative functions.

I found second use case. Look at expression: where left(str,n)='value' function left(str,n) increase monotonically for str and n. With this feature it can use index on str. Classic index needs recreating. 2011/9/25, Pavel Stehule : > Hello > > what is a real use case? > > Regards > > Pavel > >

Re: [GENERAL] New feature: accumulative functions.

... When n changes of course. Sorry for top posting, phone not allows to move cite. 2011/9/25, pasman pasmański : > I found second use case. Look at expression: > > where left(str,n)='value' > > function left(str,n) increase monotonically for str and n. With this > feature it can use index on str

Re: [GENERAL] New feature: accumulative functions.

2011/9/25 pasman pasmański : > This feature give profits for increasing muliti-arg functions. Example: > > WHERE f(x,param) = const > > it may be impossible to create functional indexes for all params. > Sorry, I asked on real use case. Do you know some one? Pavel > > > 2011/9/25, Pavel Stehule

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On Sat, Sep 24, 2011 at 11:11 PM, Albretch Mueller wrote: >> I cannot imagine you would benefit that much by removing these capabilities >> compared to simply ignoring them. >> Plus, by having it in the DB I avoid considerable considerable overhead > ~ >  Can you or do you know of anyone who has

Re: [GENERAL] New feature: accumulative functions.

I think, it should be new node in executor. Planner select classic index scan or new functional index scan. 2011/9/25, Tom Lane : > =?ISO-8859-2?Q?pasman_pasma=F1ski?= writes: >> My english is not perfect, by accumulative i think about monotonically >> increasing function. > > Oh, I see how that

Re: [GENERAL] Mac OS X shared_buffers not same as postgresql.conf file

On Sep 24, 2011, at 4:21 PM, Guillaume Lelarge wrote: > On Sat, 2011-09-24 at 14:43 -0500, Neil Tiffin wrote: >> On Sep 24, 2011, at 1:31 PM, Joe Conway wrote: >> >>> On 09/23/2011 02:33 PM, Neil Tiffin wrote: I have shared_buffers in the config file set for 32 MB and pgAdmin reports a

Re: [GENERAL] looking for a faster way to do that

At 08:04 25/09/2011, haman...@t-online.de wrote: >> select * from items where regexp_matches(items.code,'(ABC) (DE1) >> (any_substring)')<>{}; >> Hi Eduardo, it is clear that scanning the table once with a list of matches will outperform rescanning the table for every string wanted. Now, my p

Re: [GENERAL] New feature: accumulative functions.

=?ISO-8859-2?Q?pasman_pasma=F1ski?= writes: > My english is not perfect, by accumulative i think about monotonically > increasing function. Oh, I see how that would work. I can't get real excited about it though. The use-case seems a bit narrow, and the amount of complexity added to the btree s

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

> > ... you're looking for a non-sql compliant SQL database where a lot of > > the data integrity is actually coded in the application :-) > > ~ > First past of your statement I acknowledged, but how is it exactly > that "lot of the data integrity is actually coded in the application" > ~ Take

Re: [GENERAL] Mac OS X shared_buffers not same as postgresql.conf file

On Sun, 2011-09-25 at 12:13 -0500, Neil Tiffin wrote: > On Sep 24, 2011, at 4:21 PM, Guillaume Lelarge wrote: > > > On Sat, 2011-09-24 at 14:43 -0500, Neil Tiffin wrote: > >> On Sep 24, 2011, at 1:31 PM, Joe Conway wrote: > >> > >>> On 09/23/2011 02:33 PM, Neil Tiffin wrote: > I have shared_

Re: [GENERAL] New feature: accumulative functions.

My english is not perfect, by accumulative i think about monotonically increasing function. It works that for clause WHERE f(x)=const: 1. Read root page of index_on_x and get x1 ... Xn 2. Calculate f(x1) ... f(xn) for this page 3. When f(x1)<=const<= f(xn) then x1 <= searched x <= xn and we can te

Re: [GENERAL] New feature: accumulative functions.

pasman pasmański Sunday 25 of September 2011 15:19:28 > Hi. > > I propose to add "accumulative" flag to a function definition. This > flag would be set for function f(x) which is accumulative and > immutable. > > This flag allows to use an index on x for clauses containing f(x): > > where f(x)

Re: [GENERAL] pg_dump compress

Adrian Klaver writes: > On Saturday, September 24, 2011 7:16:11 am Roger Niederland wrote: >> [ pg_dump 9.1 no longer honors -Z when emitting plain text ] > Not sure why the compression was removed, there is no explanation in either > the > commit or the release notes. If you are interested, t

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

Albretch Mueller writes: > Well, at least I thought you would tell me where the postgresql-base > is to be found. The last version I found is: > > http://freebsd.csie.nctu.edu.tw/pub/distfiles/postgresql/postgresql-base-8.3beta2.tar.bz2 > and I wondered what that is and why there are no postgr

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On Sun, Sep 25, 2011 at 06:11:36AM +, Albretch Mueller wrote: > ~ > Well, at least I thought you would tell me where the postgresql-base > is to be found. The last version I found is: > ~ > > http://freebsd.csie.nctu.edu.tw/pub/distfiles/postgresql/postgresql-base-8.3beta2.tar.bz2 Notwithst

RES: [GENERAL] Alter column...using failure under 9.0.4

That's it: a check constraint I was not aware of... Thanks! Edson -Mensagem original- De: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] Em nome de Tom Lane Enviada em: domingo, 25 de setembro de 2011 13:04 Para: pgsql-general@postgresql.org; pgsql-hack...@

Re: [GENERAL] New feature: accumulative functions.

=?ISO-8859-2?Q?pasman_pasma=F1ski?= writes: > I propose to add "accumulative" flag to a function definition. This > flag would be set for function f(x) which is accumulative and > immutable. Maybe you'd better define what you mean by "accumulative" ... > This flag allows to use an index on x fo

Re: [GENERAL] Alter column...using failure under 9.0.4

=?iso-8859-1?Q?Bj=F6rn_H=E4user?= writes: > Am 25.09.2011 um 17:17 schrieb Edson Carlos Ericksson Richter: >> alter table usuario alter column ativo type smallint using (case when ativo >> then 1 else 0 end); >> ERROR: argument of IS FALSE must be type boolean, not type smallint > you could che

Re: [GENERAL] Alter column...using failure under 9.0.4

Hello, you could check for indices or something like that. Björn Am 25.09.2011 um 17:17 schrieb Edson Carlos Ericksson Richter: > Dear list, > > I’ve a strange issue here. I’ve a table that I’m sure the column type is > boolean. I can see the datatype is boolean on PgAdmin. > > Nevertheles

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On Sep 25, 2011, at 2:11 AM, Albretch Mueller wrote: > For what exactly? Isn't a comparison on 4 numeric bytes (1 (or 1/2) > word in modern hardware) more efficient than comparing sequences of > string characters? What on earth makes you think the db engine compares numbers as strings??? -- Sco

[GENERAL] Alter column...using failure under 9.0.4

Dear list, I’ve a strange issue here. I’ve a table that I’m sure the column type is boolean. I can see the datatype is boolean on PgAdmin. Nevertheless, when I issue this command alter table usuario alter co

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On 25 Sep 2011, at 8:11, Albretch Mueller wrote: >> ... and can now use those features within my SQL statements/queries. > ~ > For what exactly? Isn't a comparison on 4 numeric bytes (1 (or 1/2) > word in modern hardware) more efficient than comparing sequences of > string characters? Data types

Re: [GENERAL] New feature: accumulative functions.

On Sep 25, 2011, at 9:19, pasman pasmański wrote: > Hi. > > I propose to add "accumulative" flag to a function definition. This > flag would be set for function f(x) which is accumulative and > immutable. > > This flag allows to use an index on x for clauses containing f(x): > > where f(x) =

Re: [GENERAL] (another ;-)) PostgreSQL-derived project ...

On Sep 25, 2011, at 2:11, Albretch Mueller wrote: > ~ > Well, at least I thought you would tell me where the postgresql-base > is to be found. The last version I found is: > ~ > http://freebsd.csie.nctu.edu.tw/pub/distfiles/postgresql/postgresql-base-8.3beta2.tar.bz2 > ~ > and I wondered what tha

[GENERAL] New feature: accumulative functions.

Hi. I propose to add "accumulative" flag to a function definition. This flag would be set for function f(x) which is accumulative and immutable. This flag allows to use an index on x for clauses containing f(x): where f(x) = const where f(x) > const and so on. -- pasman -- S

Re: [GENERAL] looking for a faster way to do that

On 25 Sep 2011, at 8:04, haman...@t-online.de wrote: > Hi Eduardo, > > it is clear that scanning the table once with a list of matches will > outperform > rescanning the table for every string wanted. Now, my problem is that the > patterns are > dynamic as well. So if I could translate a table w

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

At 07:43 25/09/2011, Reuven M. Lerner wrote: Hi, everyone. Daniel Verite wrote: It would thus appear that there's a slight edge for dumping bytea, but nothing super-amazing. Deleting, however, is still much faster with bytea than large objects. The pro

Re: [GENERAL] In which case PG_VERSION file updates ?

Thanks Adrian Klaver, Provided link gives about the information of what PG_VERSION file, which am aware of:) In my observation, all the object related OID's, _fsm, _vm files under $PGDATA/base/database-oid/ directory will change as per the changes made to the database, whereas PG_VERSION file nev