-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 27/04/2011 20:48, Dave Page a écrit :
> I'm pleased to announce that effective immediately, Magnus Hagander
> will be joining the PostgreSQL Core Team.
>
> Magnus has been a contributor to PostgreSQL for over 12 years, and
> played a major part in
I have a table with the following schema:
CREATE TABLE foo (bar VARCHAR(32));
Every bar value has a format like a float, e.g. "2.5". Now I want that value
multiplied by two and saved again as varchar. I was hoping to do smth like:
UPDATE foo SET bar = TO_VARCHAR( TO_FLOAT(bar) * 2); -- INCORRECT!
2011/4/28 Thomas Larsen Wessel
> I have a table with the following schema:
> CREATE TABLE foo (bar VARCHAR(32));
>
> Every bar value has a format like a float, e.g. "2.5". Now I want that
> value multiplied by two and saved again as varchar. I was hoping to do smth
> like:
>
> UPDATE foo SET bar
On 28 April 2011 11:26, Thomas Larsen Wessel wrote:
> I have a table with the following schema:
> CREATE TABLE foo (bar VARCHAR(32));
>
> Every bar value has a format like a float, e.g. "2.5". Now I want that
> value multiplied by two and saved again as varchar. I was hoping to do smth
> like:
>
On Apr 28, 2011, at 2:56 PM, Thomas Larsen Wessel wrote:
> UPDATE foo SET bar = TO_VARCHAR( TO_FLOAT(bar) * 2); -- INCORRECT
If you are sure bar contains float value, then try following:
UPDATE foo SET bar = bar::float * 2;
Thanks & Regards,
Vibhor Kumar
EnterpriseDB Corporation
The Enterpr
2011/4/28 Vibhor Kumar
>
> On Apr 28, 2011, at 2:56 PM, Thomas Larsen Wessel wrote:
>
> > UPDATE foo SET bar = TO_VARCHAR( TO_FLOAT(bar) * 2); -- INCORRECT
>
> If you are sure bar contains float value, then try following:
> UPDATE foo SET bar = bar::float * 2;
>
NB: I am sure that OP is not
2011/4/28 Thomas Larsen Wessel
> I have a table with the following schema:
> CREATE TABLE foo (bar VARCHAR(32));
>
> Every bar value has a format like a float, e.g. "2.5". Now I want that
> value multiplied by two and saved again as varchar. I was hoping to do smth
> like:
>
> UPDATE foo SET bar
On Apr 28, 2011, at 3:22 PM, Dmitriy Igrishin wrote:
> NB: I am sure that OP is not sure :-) And since foo.bar is varchar,
> it is better to use numeric instead of float :-)
Now, this make to ask question, why numeric? How its better than float?
Thanks & Regards,
Vibhor Kumar
EnterpriseDB Cor
2011/4/28 Vibhor Kumar
>
> On Apr 28, 2011, at 3:22 PM, Dmitriy Igrishin wrote:
>
> > NB: I am sure that OP is not sure :-) And since foo.bar is varchar,
> > it is better to use numeric instead of float :-)
>
>
> Now, this make to ask question, why numeric? How its better than float?
>
Only one
On Apr 28, 2011, at 3:41 PM, Dmitriy Igrishin wrote:
> Only one point, Vibhor. I believe that varchar data type was chosen for
> exact storage of numeric values. According to chapter 8.1.3 of the doc.
> for this case the usage of numeric is preferred over floating data types.
Ah! Got it. This I h
Hello,
I have installed postgresql 9 on fedora 14 having python 2.7. Now
created plpythonu language in my database and created a simple
function to calculate sum of two variables.
while importing math libbrary and executing the function i got the error
PL/Python: ImportError: No module named cmath
It should be better in 9.1
http://archives.postgresql.org/message-id/4c2ddc9b.1060...@sigaev.ru
Oleg
On Wed, 27 Apr 2011, Mark wrote:
I have problem with GIN index. Queries over it takes a lot of time. Some
informations:
I've got a table with tsvector- textvector:
CREATE TABLE mediawiki.pageco
On 27.04.2011 19:36, Tom Lane wrote:
Erwin Brandstetter writes:
Hi all!
This may seem unimportant, but I still would like to know.
I have columns for timestamps without fractional digits, so I could
define them as timestamp(0).
However, there is no way fractions could ever enter anyway, because
Alban thanks for your quick reply.
It is true that I use for this only 2,5GB RAM on Intel Core i5 CPU 2.67GHz
and resources I didn't changed from instalation of postgres:
max_connections = 100
shared_buffers = 32MB
(other parameters are commented)
, but that would not be the reason I think.
I was
On 04/28/2011 02:19 PM, c k wrote:
Hello,
I have installed postgresql 9 on fedora 14 having python 2.7. Now
created plpythonu language in my database and created a simple
function to calculate sum of two variables.
while importing math libbrary and executing the function i got the error
PL/Pytho
* Michael Nolan:
> If you archive your WAL files, wouldn't that give you a pretty good
> indication of write activity?
WAL archiving may increase WAL traffic considerably, I think. Fresh
table contents (after CREATE TABLE or TRUNCATE) is written to the log
if WAL archiving is active. This would
* Greg Smith:
> To convert the internal numbers returned by that into bytes, you'll
> need to do some math on them. Examples showing how that works and
> code in a few languages:
Thanks for the pointers.
Those examples are slightly incongruent, but I think I've distilled
something that should b
you will have to compensate for python's version-i*i*t*c behaviour by naming
the binary to the exact version of python you are calling e.g.
mv python python5 (for python version 5 binary)
mv python python6 (for python version 6 binary)
then in each of the bash scripts you are calling reference p
One thing to remember in this discussion about SSD longevity is that the
underlying value of interest is the total number of erase cycles, per
block, on the flash devices. Vendors quote lifetime as a number of
bytes, but this is calculated using an assumed write amplification
factor. That const
Thanks a lot :)
Both of the following work
UPDATE foo SET bar = (bar::float * 2);
removes trailing zeros on the decimal side, if no decimals dont show any "."
UPDATE foo SET bar = (bar::numeric * 2);
keeps decimals, i.e. 2.000 * 2 -> 4.000
That leads me to two additional questions:
1) Can I sp
On Thu, Apr 28, 2011 at 09:15:06AM -0400, Martin Gainty wrote:
> mv python python5 (for python version 5 binary)
> mv python python6 (for python version 6 binary)
Do you happen to mean 2.5 and 2.6 ?
Given that, say, our Electronic Medical Record solution
happily runs on Python 2.5, 2.6, and 2.7
2011/4/28 Thomas Larsen Wessel
> Thanks a lot :)
>
> Both of the following work
>
> UPDATE foo SET bar = (bar::float * 2);
> removes trailing zeros on the decimal side, if no decimals dont show any
> "."
>
> UPDATE foo SET bar = (bar::numeric * 2);
> keeps decimals, i.e. 2.000 * 2 -> 4.000
>
> Th
2011/4/28 Dmitriy Igrishin
>
>
> 2011/4/28 Thomas Larsen Wessel
>
>> Thanks a lot :)
>>
>> Both of the following work
>>
>> UPDATE foo SET bar = (bar::float * 2);
>> removes trailing zeros on the decimal side, if no decimals dont show any
>> "."
>>
>> UPDATE foo SET bar = (bar::numeric * 2);
>>
Doubtful but not sure; Boolean isn't that large a structure anyway...
I'm not sure you'd want to introduce tri-value logic in this case anyway. If
you know something is false why would you claim that you don't know what the
value? Data should first and foremost be accurate and precise. In thi
Yes, there are three version (now). I am aware of only 2.7 installed
by default in /usr/lib directory and 3.2 which I have installed
externally. But the function given above shows version 2.6.4.
Now the question is how to change the version postresql is calling for
function execution?
I have also c
On Apr 28, 2011, at 7:21 AM, David Boreham wrote:
> I don't think you can simply say that I am writing so many Gb WAL files,
> therefore according to the vendor's spec
Also, I fully expect the vendors lie about erase cycles as baldly as they lie
about MTBF, so I would divide by a very healthy s
On Thursday, April 28, 2011 7:11:50 am c k wrote:
> Yes, there are three version (now). I am aware of only 2.7 installed
> by default in /usr/lib directory and 3.2 which I have installed
> externally. But the function given above shows version 2.6.4.
> Now the question is how to change the version
On 4/28/2011 8:20 AM, Scott Ribe wrote:
I don't think you can simply say that I am writing so many Gb WAL files,
therefore according to the vendor's spec
Also, I fully expect the vendors lie about erase cycles as baldly as they lie
about MTBF, so I would divide by a very healthy skepticism fac
On Wed, Apr 27, 2011 at 5:24 PM, Phoenix Kiula wrote:
> Possibly a dumb question but there isn't much about this.
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=postgresql+null+value+disk+space
> I have some BOOLEAN columns. 90% of the cases of the columns is FALSE. Do I
> save disk spa
>Do I save disk space by having them as NULL instead of FALSE? So my
>>application would have conditional code for NULL and TRUE, instead of >FALSE
>and TRUE.
The short answer:
do not even think about it.
NULL has a well defined meaning within SQL: "we do not know the
value", with "well defin
On 28 Apr 2011, at 10:07, Mark wrote:
> Alban thanks for your quick reply.
> It is true that I use for this only 2,5GB RAM on Intel Core i5 CPU 2.67GHz
> and resources I didn't changed from instalation of postgres:
> max_connections = 100
> shared_buffers = 32MB
> (other parameters are commented)
On Wed, Apr 27, 2011 at 2:48 PM, Dave Page wrote:
> I'm pleased to announce that effective immediately, Magnus Hagander
> will be joining the PostgreSQL Core Team.
Well deserved. Congratulations!
Roberto
On 28 Apr 2011, at 15:26, Thomas Larsen Wessel wrote:
> That leads me to two additional questions:
>
> 1) Can I specify how many decimals I want to be stored back from the result?
> E.g. 2 / 3 = 0. but I want to just save 0.66.
>
> 2) Can I make a criteria that it should only update on
On 28 Apr 2011, at 17:29, Alban Hertroys wrote:
> With 2.5GB of memory (such a strange number) the docs suggest about 250MB.
Correction, 25% of 2.5GB isn't 250MB of course. It would be somewhat over
500MB, although it's really just a rule-of-thumb (no point in calculating exact
numbers). Anyway,
I appreciate the advice. But in this particular case, other people have
decided for me that I should not change the schema. I guess they have their
reasons :)
On Thu, Apr 28, 2011 at 5:40 PM, Alban Hertroys <
dal...@solfertje.student.utwente.nl> wrote:
> On 28 Apr 2011, at 15:26, Thomas Larsen We
It seems that the 'mysql2postgres.pl' tool has instructions embedded
into the file so I ran the command as instructed to take the output
file and insert it into my PostgreSQL server and got the following
error message:
$ psql -p 5432 -h db1 -U wiki -f mediawiki_upgrade.pg
Password for user wiki:
B
Now, I found that python version postresql is using is 2.6 and path to it is
"['/home/apy/rrun/build/activepython-svn-trunk/build/py2_6_4-linux-x86-apy26-rrun/CoReAcTiVePyThOnPrEfIxCoReAcTiVePyThOnPrEfIxCoReAcTiVePyThOnPrEfIxCoReAcTiVePyThOnPrEfIxCoReAcTiVePyThOnPrEfIxCoReAcTiVePyThOnPrEfIxCoReAcT
On Apr 28, 2011, at 8:48 AM, David Boreham wrote:
> As a former card-carrying semiconductor company employee, I'm not so sure
> about this.
Well, yes, you have a good point that in many, if not all, cases we're dealing
with different companies. That really should have occurred to me, that
manu
Cheers!
Solved.
What I did is complied source with python option (it failed even giving
correct python 3.2 as per instruction given in the manual page you have
shown) for python 2.7. From build and installed postgresql, copied
plpython2.so and plpython.so to the developement server and restarted it
A colleague of mine insists that using surrogate keys is the
common practice by an overwhelming margin in relational databases and
that they are used in 99 percent of large installations. I agree that many
situations benefit from them, but are they really as pervasive
as he claims?
Thanks,
- Jim
On 4/28/2011 12:29 PM, Jim Irrer wrote:
A colleague of mine insists that using surrogate keys is the
common practice by an overwhelming margin in relational databases and
that they are used in 99 percent of large installations. I agree that many
situations benefit from them, but are they really
On 04/28/2011 11:44 AM, Andy Colson wrote:
On 4/28/2011 12:29 PM, Jim Irrer wrote:
A colleague of mine insists that using surrogate keys is the
common practice by an overwhelming margin in relational databases and
that they are used in 99 percent of large installations. I agree that
many
situa
On Thu, Apr 28, 2011 at 01:29:31PM -0400, Jim Irrer wrote:
> common practice by an overwhelming margin in relational databases and
> that they are used in 99 percent of large installations.
94.68536% of all the claims I ever hear are obviously pulled out of
thin air.
What conclusion does your
On 04/28/2011 10:29 AM, Jim Irrer wrote:
A colleague of mine insists that using surrogate keys is the
common practice by an overwhelming margin in relational databases and
that they are used in 99 percent of large installations. I agree that
many
situations benefit from them, but are they real
On Apr 28, 2011, at 11:53 AM, Rob Sargent wrote:
> Hm, I get the feeling that only the good folks at Hibernate seem to think
> using a "natural key" is the _only_ way to go.
Well, natural keys are quite obviously the way to go, when they exist. The
problem is, they usually don't really exist. W
On Thu, Apr 28, 2011 at 7:26 PM, Joshua D. Drake wrote:
> Well there is no fact to back that up but, I will say that most toolkits
> require the use of a synthetic key, rails, django etc
Usually such tools are born with surrogate keys only, because it's
easier, and either grow up developing
Excellent Notice
Success for All
Kind Best Regard
Ernesto Lozano
Director General
Hia Technology de Venezuela
ISV/ de EnterpriseDB for Venezuela , Colombia
Member Community Postgresql Venezuela and Latin America
www.hiatechnology.com.ve
eloz...@hiatechnology.com.ve
v...@postgresql.org
Twitter: e
In PL/pgSQL, how does one generically access the fields of the OLD or NEW
record?
I've tried code such as this:
'NEW.' || quote_ident( myColumnNameVar ) || '::varchar'
But when run by an "EXECUTE" command, I get errors such as:
ERROR: missing FROM-clause entry for table "old"
SQL state:
On Thu, Apr 28, 2011 at 12:46:50PM -0700, Basil Bourque wrote:
> In PL/pgSQL, how does one generically access the fields of the OLD or NEW
> record?
>
> I've tried code such as this:
> 'NEW.' || quote_ident( myColumnNameVar ) || '::varchar'
>
> But when run by an "EXECUTE" command, I get erro
On Thu, Apr 21, 2011 at 12:10 PM, Greg Smith wrote:
> On 04/21/2011 11:33 AM, Florian Weimer wrote:
>>
>> Is there an easy way to monitor WAL traffic in away? It
>> does not have to be finegrained, but it might be helpful to know if
>> we're doing 10 GB, 100 GB or 1 TB of WAL traffic on a particul
On Apr 28, 2011, at 3:46 PM, Basil Bourque wrote:
> It seems that I cannot get PL/pgSQL to interpret the text of "NEW." + column
> name as text.
>
> My goal is to loop each field in a trigger, comparing the "OLD." & "NEW."
> values of each field. If different I want to log both values in a
>
On 2011-04-28 21:34, Robert Treat wrote:
We have an open task to work on this same problem. What we had cobbled
together so far was some sql which converted the xlog value into an
integer (it's pretty ugly, but I could send it over if you think it
would help), which we could then stick in a moni
On Thu, Apr 28, 2011 at 12:29 PM, Jim Irrer wrote:
> A colleague of mine insists that using surrogate keys is the
> common practice by an overwhelming margin in relational databases and
> that they are used in 99 percent of large installations. I agree that many
> situations benefit from them, bu
Any system that generates transactional data has to use some kind of
synthetic key. I guess you could rely upon some form of timestamp but from
a usability standpoint that is not really a good decision. Inventory also
requires synthetic keys - whether you decide what they are or someone else
does
On Thu, Apr 28, 2011 at 03:39:19PM -0500, Merlin Moncure wrote:
> They are fairly pervasive, and increasingly so, which I find to be
> really unfortunate. Personally I think rote use of surrogate keys is
> terrible and leads to bad table designs, especially if you don't
> identify the true natura
On Thu, 2011-04-28 at 07:29 +0200, pasman pasmański wrote:
> Hi. Yesterday i have an idea, that sometimes row locks may be skipped,
> when table is already locked with LOCK command. It may to reduce an
> overhead from row locks.
> What do you think about it?
The table-level lock mode would need to
Instead of the usual SSD, you may want to consider the 'ioDrive' products from
"Fusion-io".
http://www.fusionio.com/
This company makes enterprise-class storage on a board populated with flash and
managed by their own supposedly-sophisticated drivers. The board + drivers are
meant to get around
On Thu, 28 Apr 2011 17:27:04 -0500, Basil Bourque
wrote:
So, while I can't specifically recommend their products, I certainly
suggest considering them.
Customer of ours is probably lurking on here. We host their servers in our
datacenter -- we had a UPS go "pop" after an amazing surge an
Hi,
A database I'm handling is becoming a bit large'ish (~ 30 tables), and
I'd like to break them down into their natural units. Schemas for each
of these natural units seems logical, but are they really meant for
this? I'm also worried about how this would affect programs like
Libreoffice (the
On 04/28/11 5:51 PM, Seb wrote:
Hi,
A database I'm handling is becoming a bit large'ish (~ 30 tables), and
I'd like to break them down into their natural units. Schemas for each
of these natural units seems logical, but are they really meant for
this? I'm also worried about how this would affe
On Thu, 28 Apr 2011 18:15:05 -0700,
John R Pierce wrote:
> On 04/28/11 5:51 PM, Seb wrote:
>> Hi,
>> A database I'm handling is becoming a bit large'ish (~ 30 tables),
>> and I'd like to break them down into their natural units. Schemas
>> for each of these natural units seems logical, but are
Seb wrote:
A database I'm handling is becoming a bit large'ish (~ 30 tables), and
I'd like to break them down into their natural units. Schemas for each
of these natural units seems logical, but are they really meant for
this? I'm also worried about how this would affect programs like
Libreoffi
On Thu, 28 Apr 2011 19:29:11 -0700,
Darren Duncan wrote:
> Seb wrote:
>> A database I'm handling is becoming a bit large'ish (~ 30 tables),
>> and I'd like to break them down into their natural units. Schemas
>> for each of these natural units seems logical, but are they really
>> meant for this
On 22/04/11 01:33, Florian Weimer wrote:
* Greg Smith:
The fact that every row update can temporarily use more than 8K means
that actual write throughput on the WAL can be shockingly large. The
smallest customer I work with regularly has a 50GB database, yet they
write 20GB of WAL every day.
On 04/26/2011 10:30 AM, Toby Corkindale wrote:
I see Intel is/was claiming their SLC SSDs had a *minimum* lifetime of
2PB in writes for their 64GB disks; for your customer with a 50GB db
and 20GB/day of WAL, that would work out at a minimum lifetime of a
million days, or about 273 years!
The c
Seb wrote:
Thanks for these thoughts. Perhaps I can describe a cartoon of this
database to explain what I'm trying to accomplish.
The database stores information related to biological research. The
bulk of the tables describe things like individual ID, morphometrics,
and behavioural data on al
On 29 Apr 2011, at 5:03, Seb wrote:
> So typically we have two types of uses: research and
> preparation/logistics for the project. We wouldn't want to even see the
> logistcs tables for research work, whereas we would like to see only
> these ones for preparation/planning. As the project and nu
67 matches
Mail list logo
