On Sun, Dec 11, 2016 at 2:39 PM, Qiu Xiafei wrote:
> Because of the one-backend-per-session concept of PG, I think I should bind
> one my DSL session to one bg worker only. It seems work. But is there a way
> to launch a bg worker when a new session starts, just like pg's
> per-session-backend do?
Thank you Adrian.
That was it.
Now I can continue testing.
On Sat, Dec 10, 2016 at 11:26 PM, Adrian Klaver
wrote:
> On 12/10/2016 06:56 PM, Igor Korot wrote:
>>
>> Hi,
>>
>> On Sat, Dec 10, 2016 at 2:50 PM, John R Pierce
>> wrote:
>>>
>>> On 12/10/2016 11:32 AM, Igor Korot wrote:
On 12/10/2016 06:56 PM, Igor Korot wrote:
Hi,
On Sat, Dec 10, 2016 at 2:50 PM, John R Pierce wrote:
On 12/10/2016 11:32 AM, Igor Korot wrote:
Looking
athttps://www.postgresql.org/docs/9.5/static/datatype-numeric.html,
I don't see a 'boolean' as supported data type.
thats because boolean i
shreeyansh,
we have issue with relation and we have fixed this using setting
zero_damaged_pages and then running vacuum fullbon relatuon.
I am looking at possibility of PG introducing corruption if relation
extends and before it updates new page with pageheader in memory and crash
happens?
Is thi
Hi,
On Sat, Dec 10, 2016 at 2:50 PM, John R Pierce wrote:
> On 12/10/2016 11:32 AM, Igor Korot wrote:
>>
>> Looking
>> athttps://www.postgresql.org/docs/9.5/static/datatype-numeric.html,
>> I don't see a 'boolean' as supported data type.
>
>
> thats because boolean isn't a number, its a true/fals
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
Hi,
On 2016-12-10 22:34:02 +0100, Torsten Förtsch wrote:
> I am working on a logical decoding output plugin. I am only interested in
> the changes in one particular table.
>
> One way to check for the table would be to compare class_form->relname
> and get_namespace_name(class_form->relnamespace)
On 2016-12-09 21:45:35 -0500, Melvin Davidson wrote:
> On Fri, Dec 9, 2016 at 6:40 PM, Samuel Williams
>
> wrote:
> >I also read that when you change a column which is not index, all the
> >indexes for that row need to be updated anyway. Is that correct?
>
> That is not correct. Indexes are chan
Hi,
I am working on a logical decoding output plugin. I am only interested in
the changes in one particular table.
One way to check for the table would be to compare class_form->relname
and get_namespace_name(class_form->relnamespace). But I'd much prefer to
just compare the OID of the table.
Is
On 12/10/2016 11:32 AM, Igor Korot wrote:
Looking athttps://www.postgresql.org/docs/9.5/static/datatype-numeric.html,
I don't see a 'boolean' as supported data type.
thats because boolean isn't a number, its a true/false value.
https://www.postgresql.org/docs/current/static/datatype-boolean.ht
2016-12-10 20:43 GMT+01:00 Pavel Stehule :
>
>
> 2016-12-10 20:32 GMT+01:00 Igor Korot :
>
>> Hi, guys,
>> I'm working thru my script and I hit a following issue:
>>
>> In the script I have a following command:
>>
>> CREATE TABLE playersinleague(id integer, playerid integer, ishitter
>> char, age
> On Dec 10, 2016, at 11:32 AM, Igor Korot wrote:
>
> Hi, guys,
> I'm working thru my script and I hit a following issue:
>
> In the script I have a following command:
>
> CREATE TABLE playersinleague(id integer, playerid integer, ishitter
> char, age integer, value decimal, currvalue decimal,
2016-12-10 20:32 GMT+01:00 Igor Korot :
> Hi, guys,
> I'm working thru my script and I hit a following issue:
>
> In the script I have a following command:
>
> CREATE TABLE playersinleague(id integer, playerid integer, ishitter
> char, age integer, value decimal, currvalue decimal, draft boolean,
Hi, guys,
I'm working thru my script and I hit a following issue:
In the script I have a following command:
CREATE TABLE playersinleague(id integer, playerid integer, ishitter
char, age integer, value decimal, currvalue decimal, draft boolean,
isnew char(1), current_rank integer, original_rank in
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 15:41 GMT+01:00 Adrian Klaver :
> On 12/10/2016 04:21 AM, Tom DalPozzo wrote:
>
>> Hi,
>> my release is 9.5.4.
>> a took a look over it. I guessed that counting could be slow because it
>> needs to read everything and also that it can take advantage from an
>> index. But I don't underst
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+
On 12/10/2016 04:21 AM, Tom DalPozzo wrote:
Hi,
my release is 9.5.4.
a took a look over it. I guessed that counting could be slow because it
needs to read everything and also that it can take advantage from an
index. But I don't understand why the delay is after the updates for a
Best guess, a
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
The R statistic software is using PostgreSQL. Oracle has a module to
transform PostgreSQL tables very easy both ways. Just install R and the
module. I can't remember the name of the module but try googling.
Hope it helps.
/Poul
2016-12-09 18:22 GMT+01:00 Joanna Xu :
> Hi All,
>
>
>
> We plan
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
Hi,
my release is 9.5.4.
a took a look over it. I guessed that counting could be slow because it
needs to read everything and also that it can take advantage from an index.
But I don't understand why the delay is after the updates for a certain
time and why WHERE..IN is much faster (ok, it's an in
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 rows each time, changing d0
filed keepi
34 matches
Mail list logo
