Thanks for the comprehensive reply. It definitely cleared a lot of things up
for me.
regards
Sandeep
On Mon, Aug 16, 2010 at 12:39 PM, Greg Smith wrote:
> Sandeep Srinivasa wrote:
>
>>
>> I was looking at ways to optimize the postgres database and yet limit the
>> amount of memory that it can c
On 17/08/10 06:59, Andy wrote:
> http://www.scribd.com/doc/2569473/Migrating-from-PostgreSQL-to-MySQL-at-Cocolog-Japans-Largest-Blog-Community
>
> Are there any reasons why table & index sizes of Postgresql should be larger
> than MySQL? Postgresql uses MVCC while InnoDB does not use "full" MVCC
Can anyone answer me ?
Thanks you very much
Tuan Hoang Anh
On Sat, Aug 14, 2010 at 10:00 AM, tuanhoanganh wrote:
> I tried to do pitr backup using Postgres 8.3.9 on windows. So I issued
> SELECT pg_start_backup('test');
> After I put the db in backup mode I tried to zip the data directory files
Andy writes:
> Your results of 867MB for Postgresql & 3,576 MB for InnoDB are surprising. Do
> you know why it is so much smaller for Postgresql? Are there any indexes?
If I understood the original report correctly, they were complaining
mostly about index size, so a table without indexes certai
Not really. NULLs are stored in a bit field. Each null takes up one
bit in this field, and as you add more nulls, you get more bytes each
time you go over a multiple of 8.
Also, NULLS can be indexed in postgresql now. Older versions could
not index nulls (actually they got indexed, but the entr
Hello everyone, I have a doubt:
A null value in a field could affect the performance of the database??
Regards.
Thank you very much for your time.
- "Digimer" escribió:
> On 10-08-16 09:51 PM, Lazaro Ruben Garcia Martinez wrote:
> > Hola a todos, desde hace mucho tiempo tengo una una d
On 10-08-16 09:51 PM, Lazaro Ruben Garcia Martinez wrote:
> Hola a todos, desde hace mucho tiempo tengo una una duda relacionada con
> los campos nullos, quería saber si tanto el empleo como la presencia de
> los mismos ya sea en tablas pequeñas o grandes, pude afectar de alguna
> forma el rendimie
Hola a todos, desde hace mucho tiempo tengo una una duda relacionada con los
campos nullos, quería saber si tanto el empleo como la presencia de los mismos
ya sea en tablas pequeñas o grandes, pude afectar de alguna forma el
rendimiento del sistema, ademas quisiera saber que inconvenientes puede
--- On Mon, 8/16/10, Thom Brown wrote:
> This is quite a crude and unrealistic test (as you'd need a
> set of
> real-world data), but just did a quick test using
> PostgreSQL 9.0 alpha
> 4 and MySQL . I created a new database in both
> PostgreSQL and MySQL.
> Created the same table in both, an
On 16 August 2010 23:59, Andy wrote:
> For the same data set, with mostly text data, how does the data (table +
> index) size of Postgresql compared to that of MySQL?
>
> In this presentation, the largest blog site in Japan talked about their
> migration from Postgresql to MySQL. One of their re
Andy writes:
> Are there any reasons why table & index sizes of Postgresql should be larger
> than MySQL?
Well, the per-row headers in PG are definitely bigger because of MVCC
requirements. It's hard to speculate much about index sizes with
no information about the table/index schemas.
> The c
For the same data set, with mostly text data, how does the data (table + index)
size of Postgresql compared to that of MySQL?
In this presentation, the largest blog site in Japan talked about their
migration from Postgresql to MySQL. One of their reasons for moving away from
Postgresql was that
Excerpts from Boszormenyi Zoltan's message of lun ago 16 14:45:07 -0400 2010:
> Matthew Wilson írta:
> > I don't care if the code is rearranged so that c is replaced with an
> > inline definition during compilation. I'm not concerned about
> > efficiency here. I just don't want to have to redefi
2010/8/16 Boszormenyi Zoltan :
> Matthew Wilson írta:
>> On Mon Aug 16 10:26:36 2010, Tom Lane wrote:
>>
>>> Matthew Wilson writes:
>>>
All I can come up with so far is to use a view and then another view on
top of that one:
>>> Note that you don't actually need a view, as you can j
Matthew Wilson írta:
> On Mon Aug 16 10:26:36 2010, Tom Lane wrote:
>
>> Matthew Wilson writes:
>>
>>> All I can come up with so far is to use a view and then another view on
>>> top of that one:
>>>
>> Note that you don't actually need a view, as you can just write the
>> subselect
Peter C. Lai wrote:
> The doublequotes isn't UTF8 it's people copying and pasting from Microsoft
> stuff, which is WIN-1252. So try to use that with iconv instead of utf8
>
> On 2010-08-16 12:40:03PM -0500, Karl Denninger wrote:
>
>> So I have myself a nice pickle here.
>>
>> I've got a data
On Mon Aug 16 10:26:36 2010, Tom Lane wrote:
> Matthew Wilson writes:
>> All I can come up with so far is to use a view and then another view on
>> top of that one:
>
> Note that you don't actually need a view, as you can just write the
> subselect in-line:
>
> select a, b, c,
> case whe
The doublequotes isn't UTF8 it's people copying and pasting from Microsoft
stuff, which is WIN-1252. So try to use that with iconv instead of utf8
On 2010-08-16 12:40:03PM -0500, Karl Denninger wrote:
> So I have myself a nice pickle here.
>
> I've got a database which was originally created
So I have myself a nice pickle here.
I've got a database which was originally created with SQL_ASCII for the
encoding (anything goes text fields)
Unfortunately, I have a bunch of data that was encoded in UTF-8 that's
in an RSS feed that I need to load into said database. iconv barfs all
over
On 16 Aug 2010, at 10:45,
wrote:
> Hi Alban,
>
> Thanks for the reply.
>
> I checked that Notify will not work till the transaction is commited. So in
> our case since the transaction is being rolled back there will be no notify.
Ah, you're right! I totally forgot about that...
> Is there
The answer is quite simple: this statement was composed by several functions
used for ordering on string values as also on numeric.
--- Thomas Kellerer schrieb am So, 15.8.2010:
> Von: Thomas Kellerer
> Betreff: Re: [GENERAL] Wrong "ORDER BY" on a numeric value result
> An: pgsql-general@pos
Hello everyone,
I'm trying to code a function that processes records from various tables
performing the same action in each case. The functions receives as an
argument a RECORD type variable and I'd like to iterate through each of its
elements. According to the documentation here:
http://python.p
Am 16.08.2010 14:45, schrieb Matthew Wilson:
I'm converting some procedural code to SQL as an experiment. Here's the
pseudocode:
c = a - b
if c< 0 then d = 'no'
else d = 'yes'
In SQL, I've got this:
select a, b, a - b as c,
case when a - b< 0 then 'no'
else 'ye
Matthew Wilson writes:
> All I can come up with so far is to use a view and then another view on
> top of that one:
Note that you don't actually need a view, as you can just write the
subselect in-line:
select a, b, c,
case when c < 0 then 'no'
else 'yes'
end as d
from (
I'm converting some procedural code to SQL as an experiment. Here's the
pseudocode:
c = a - b
if c < 0 then d = 'no'
else d = 'yes'
In SQL, I've got this:
select a, b, a - b as c,
case when a - b < 0 then 'no'
else 'yes'
end as d
from foo;
This is a trivial exa
Heyho!
[[ logging from postgres ]]
I think you can use dblink to do this - everything you do via dblink happens
in a separate db session and so it shouldn't be affected by what happens in
your transaction.
Depending on your requirements, system resources may be an issue though
(you're opening
Hello,
... The simplest explanation
I can think of is that it's *only* shmctl that is malfunctioning, not
the other SysV shared memory calls. Which is even weirder, and
definitely seems to move the problem into the category of kernel bug
rather than configuration mistake.
Hmmm ... Google turn
Hi Alban,
Thanks for the reply.
I checked that Notify will not work till the transaction is commited. So in our
case since the transaction is being rolled back there will be no notify. I am
new to Postgres so i am not sure how to run LISTEN as demon so that it keeps on
running to be notified.
Sandeep Srinivasa wrote:
I was looking at ways to optimize the postgres database and yet limit
the amount of memory that it can consume.
You can't usefully limit the amount of memory that PostgreSQL will
consume yet. Each client can easily allocate multiples of work_mem
worth of memory as
29 matches
Mail list logo
