Il 12/12/2016 02:42, David G. Johnston ha scritto:
On Saturday, December 10, 2016, Tom DalPozzo mailto:t.dalpo...@gmail.com>> wrote:
I have one direct DB client (let's name it MIDAPP) only. This
client of the DB is a server for up to 1 final clients.
Any time M
On Saturday, December 10, 2016, Tom DalPozzo wrote:
>
> I have one direct DB client (let's name it MIDAPP) only. This client of
> the DB is a server for up to 1 final clients.
> Any time MIDAPP is going to reply to a client, it must save a "status
> record with some data" related to that cli
Please use a readable font. Your messages are using a font that's so small that
my eyes start to hurt. I still try to read them, but I - and I assume others -
will stop trying if you keep this up.
Sorry for the top-post, but since it's not directly appropriate to the topic
that's perhaps for th
On 12/10/2016 10:15 AM, Tom DalPozzo wrote:
2016-12-10 18:30 GMT+01:00 Francisco Olarte mailto:fola...@peoplecall.com>>:
A couple of things first.
1.- This list encourages inline replying, editing the text, and frowns
upon top posting.
2.- Your HTML formatting with so a small
On 12/10/2016 09:30 AM, Francisco Olarte wrote:
A couple of things first.
1.- This list encourages inline replying, editing the text, and frowns
upon top posting.
2.- Your HTML formatting with so a small size makes it harder for me (
and I can assume some others ) to properly read your messages
2016-12-10 18:30 GMT+01:00 Francisco Olarte :
> A couple of things first.
>
> 1.- This list encourages inline replying, editing the text, and frowns
> upon top posting.
>
> 2.- Your HTML formatting with so a small size makes it harder for me (
> and I can assume some others ) to properly read your
2016-12-10 18:33 GMT+01:00 Francisco Olarte :
> Tom:
>
> On Sat, Dec 10, 2016 at 6:01 PM, Tom DalPozzo
> wrote:
> > As for crash proof, I meant that once my client app is told that her
> update
> > request was committed, it mustn't get lost (hdd failure apart of course).
> > And I can't wait to f
Tom:
On Sat, Dec 10, 2016 at 6:01 PM, Tom DalPozzo wrote:
> As for crash proof, I meant that once my client app is told that her update
> request was committed, it mustn't get lost (hdd failure apart of course).
> And I can't wait to flush the cache before telling to the app :"committed".
> I can
A couple of things first.
1.- This list encourages inline replying, editing the text, and frowns
upon top posting.
2.- Your HTML formatting with so a small size makes it harder for me (
and I can assume some others ) to properly read your messages.
If you want to discourage people replying to yo
2016-12-10 18:10 GMT+01:00 Rob Sargent :
>
> > On Dec 10, 2016, at 10:01 AM, Tom DalPozzo wrote:
> >
> > 2016-12-10 16:36 GMT+01:00 Rob Sargent :
> >
> > > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo
> wrote:
> > >
> > > Hi,
> > > I'd like to do that! But my DB must be crash proof! Very high
> rel
> On Dec 10, 2016, at 10:01 AM, Tom DalPozzo wrote:
>
> 2016-12-10 16:36 GMT+01:00 Rob Sargent :
>
> > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo wrote:
> >
> > Hi,
> > I'd like to do that! But my DB must be crash proof! Very high reliability
> > is a must.
> > I also use sycn replication.
> >
2016-12-10 16:36 GMT+01:00 Rob Sargent :
>
> > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo wrote:
> >
> > Hi,
> > I'd like to do that! But my DB must be crash proof! Very high
> reliability is a must.
> > I also use sycn replication.
> > Regards
> > Pupillo
> >
> >
> >
> >
> > Are each of the updat
> On Dec 10, 2016, at 7:27 AM, Tom DalPozzo wrote:
>
> Hi,
> I'd like to do that! But my DB must be crash proof! Very high reliability is
> a must.
> I also use sycn replication.
> Regards
> Pupillo
>
>
>
>
> Are each of the updates visible to a user or read/analyzed by another
> activity?
Hi,
I'd like to do that! But my DB must be crash proof! Very high reliability
is a must.
I also use sycn replication.
Regards
Pupillo
2016-12-10 16:04 GMT+01:00 Rob Sargent :
>
> > On Dec 10, 2016, at 6:25 AM, Tom DalPozzo wrote:
> >
> > Hi,
> > you're right, VACUUM FULL recovered the space,
> On Dec 10, 2016, at 6:25 AM, Tom DalPozzo wrote:
>
> Hi,
> you're right, VACUUM FULL recovered the space, completely.
> So, at this point I'm worried about my needs.
> I cannot issue vacuum full as I read it locks the table.
> In my DB, I (would) need to have a table with one bigint id field+
Hi,
you're right, VACUUM FULL recovered the space, completely.
So, at this point I'm worried about my needs.
I cannot issue vacuum full as I read it locks the table.
In my DB, I (would) need to have a table with one bigint id field+ 10 bytea
fields, 100 bytes long each (more or less, not fixed).
5
Hi Tom
On Sat, Dec 10, 2016 at 1:15 PM, Tom DalPozzo wrote:
...
> Reported table size is 1.5MB. OK.
That's 150 bytes per row, prety normal.
> Now, for 1000 times, I update 2000 different rows each time, changing d0
> filed keeping the same length, and at the end of all, I issued VACUUM.
And p
Tom DalPozzo wrote:
> Hi,
> I've a table ('stato') with an indexed bigint ('Id') and 5 bytea fields
> ('d0','d1',...,'d4').
> I populated the table with 1 rows; each d.. field inizialized with 20
> bytes.
> Reported table size is 1.5MB. OK.
> Now, for 1000 times, I update 2000 different row
18 matches
Mail list logo
