Hi,
I use PostgreSQL 9.6 (9.6.3) with table partitioning, when I use INSERT order
psql, it does not show the number of lines inserted.
I do not see any information in the version notes from the PostgreSQL
documentation, even with the 9.6.5 update, is it some bug ?
Here is a short test case :
What is the (min, max, avg) size of the inserted text ?
-
PAscal
SQLeo projection manager
Senior Oracle dba migrating towards PostgreSQL
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
Can't get to hard data right now, but those are app logs that try to be
no more than ~100 bytes characters long for readability, and also HTTP
logs with long-ish request lines which might put it in the neighborhood
of 2K characters.
On 10/18/2017 02:30 AM, legrand legrand wrote:
What is the
I saw a similar project on oracle that was storing (long) messages (clob).
Partionning by creation date was in place, as btree indexes to access data
per id. It was working fine for inserts, as for sélect, but purges (delete)
where not freeing space. In fact rétention was not the same for all
rec
Friendly greetings !
You may want to take a look at a postgresql "fork" called pipelinedb :
https://www.pipelinedb.com/
https://github.com/pipelinedb/pipelinedb
I'm not working for them, not using it, but i happen to know it exist :)
*hugs*
--
Laurent "ker2x" Laborde
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?
It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed
when
moving from 8.4 and 9.2?
It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several yea
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?
It's entirely possible you'll need *less*, a
On 18/10/2017 17:34, Igal @ Lucee.org wrote:
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?
It's entirely possible you'll need *less*, as y
In Postgres 10 Windows
invoking g_dump exe with
pg_dump.exe -b -f b.backup -Fc -h -U admin -p 5432 mydb
causes error
pg_dump: too many command-line arguments (first is "-p")
Try "pg_dump --help" for more information.
How to fix this ?
In earlier versions it worked.
Andrus
--
Sent via p
On Wed, Oct 18, 2017 at 8:05 AM, Andrus wrote:
> pg_dump.exe -b -f b.backup -Fc -h -U admin -p 5432 mydb
>
> causes error
>
> pg_dump: too many command-line arguments (first is "-p")
Don't you need a hostname after -h? I think right now pg_dump thinks
your hostname is "-U", your database is "adm
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?
There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronou
Hi,
I have a program that saves information in a DB Postgresql need to extract
data from date and time of that DB but when I retrieve the date and time
information is always ahead 3 hours, the type of data that has that field
is timestamp without time zone,
Please forgive my english I'm using tr
On Wed, Oct 18, 2017 at 8:21 AM, américo bravo astroña <
americobr...@gmail.com> wrote:
> Hi,
>
> I have a program that saves information in a DB Postgresql need to extract
> data from date and time of that DB but when I retrieve the date and time
> information is always ahead 3 hours, the type of
Where is the machine running the database physically located, in another
timezone possibly?
bobb
On Oct 18, 2017, at 10:33 AM, David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
On Wed, Oct 18, 2017 at 8:21 AM, américo bravo astroña
mailto:americobr...@gmail.com>> wrote:
Hi,
I hav
On Wed, Oct 18, 2017 at 8:16 AM, Igal @ Lucee.org wrote:
> On 10/18/2017 7:45 AM, Ron Johnson wrote:
>
> On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
>
> A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
> 10.0?
>
>
> There's no way we're going to put an x.0.0 version into p
On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0?
There's no way we're going to put an x.0.0 version into production.
Then think
On Wed, Oct 18, 2017 at 11:46 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Wed, Oct 18, 2017 at 8:16 AM, Igal @ Lucee.org wrote:
>
>> On 10/18/2017 7:45 AM, Ron Johnson wrote:
>>
>> On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
>>
>> A bit off-topic here, but why upgrade to 9
On 10/18/2017 08:49 AM, Ron Johnson wrote:
On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?
There's no way we're going to put an
On 10/18/2017 10:24 AM, STERBECQ Didier wrote:
> Hi,
>
> I use PostgreSQL 9.6 (9.6.3) with table partitioning, when I use INSERT
> order psql, it does not show the number of lines inserted.
>
> I do not see any information in the version notes from the PostgreSQL
> documentation, even with the 9
On Wed, Oct 18, 2017 at 11:26 AM, Joshua D. Drake
wrote:
> On 10/18/2017 08:49 AM, Ron Johnson wrote:
>>
>> On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
>>>
>>> On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
>
> A bit off-topic here,
Hi all,
is there a "official" monitoring tool for PostgreSQL databases? For
example, i come from Oracle Database, and there, we have Enterprise Manager
to monitor and administrer the product... is there such a similar tool for
PostgreSQL?
Thanks for the attention.
--
*Fabrício Pedroso Jorge.
On Wed, Oct 18, 2017 at 11:37 AM, Fabricio Pedroso Jorge
wrote:
> Hi all,
>
>is there a "official" monitoring tool for PostgreSQL databases? For
> example, i come from Oracle Database, and there, we have Enterprise Manager
> to monitor and administrer the product... is there such a similar too
We use a PERL script to handle this sort of thing. It’s nice this way since we
can run them from just about anywhere.
bobb
On Oct 18, 2017, at 12:37 PM, Fabricio Pedroso Jorge
mailto:fpjb...@gmail.com>> wrote:
Hi all,
is there a "official" monitoring tool for PostgreSQL databases? For ex
On 10/18/2017 05:57 PM, Melvin Davidson wrote:
>
> On Wed, Oct 18, 2017 at 11:46 AM, David G. Johnston
> mailto:david.g.johns...@gmail.com>> wrote:
>
> The contributors do an excellent job but the reality of this
> community is that a critical mass of people do not start seriously
> t
Fabricio Pedroso Jorge schrieb am 18.10.2017 um 19:37:
is there a "official" monitoring tool for PostgreSQL databases? For
example, i come from Oracle Database, and there, we have Enterprise
Manager to monitor and administrer the product... is there such a
similar tool for PostgreSQL?
There is
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
wrote:
> On 10/18/2017 05:57 PM, Melvin Davidson wrote:
> >
> > I support the policy of using caution with regards to new versions. They
> > are often thought of as "bleeding edge" for the reason described by
> > David G Johnston. The fact that Postgre
On Wednesday, October 18, 2017, Joshua D. Drake
wrote:
>
> I am not sure why this is even a question. There are plenty of businesses
> that can risk the deployment of a .0 release but there are also *MANY THAT
> CAN NOT*. The proper way to do this is to have a staging server running the
> .0 relea
On 10/18/2017 11:17 AM, Don Seiler wrote:
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
mailto:vik.fear...@2ndquadrant.com>> wrote:
On 10/18/2017 05:57 PM, Melvin Davidson wrote:
>
> I support the policy of using caution with regards to new versions. They
> are often thought of a
On 10/18/2017 08:17 PM, Don Seiler wrote:
> On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> On 10/18/2017 05:57 PM, Melvin Davidson wrote:
> >
> > I support the policy of using caution with regards to new versions. They
> > are often t
On 18/10/2017 18:37, Fabricio Pedroso Jorge wrote:
Hi all,
is there a "official" monitoring tool for PostgreSQL databases? For
example, i come from Oracle Database, and there, we have Enterprise
Manager to monitor and administrer the product... is there such a
similar tool for PostgreSQL?
On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing
wrote:
> On 10/18/2017 08:17 PM, Don Seiler wrote:
>
> > I disagree with this. It isn't my company's business to test the
> > Postgres software in development, as much as it would be needed and
> > appreciated by the community.
>
> Yeah, let others do
On Wed, Oct 18, 2017 at 2:34 PM, Don Seiler wrote:
> On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing
> wrote:
>
>> On 10/18/2017 08:17 PM, Don Seiler wrote:
>>
>> > I disagree with this. It isn't my company's business to test the
>> > Postgres software in development, as much as it would be needed
On 18 October 2017 at 17:17, Vik Fearing wrote:
> On 10/18/2017 08:17 PM, Don Seiler wrote:
>> On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
>> mailto:vik.fear...@2ndquadrant.com>> wrote:
>>
>> On 10/18/2017 05:57 PM, Melvin Davidson wrote:
>> >
>> > I support the policy of using cautio
On 19/10/17 10:34, Don Seiler wrote:
On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing
mailto:vik.fear...@2ndquadrant.com>> wrote:
On 10/18/2017 08:17 PM, Don Seiler wrote:
> I disagree with this. It isn't my company's business to test the
> Postgres software in development, as much as
Hello,
I’m running into problems with the restriction on pgpass file types. When
attempting to use something like an anonymous pipe for a passfile, psql
throws an error stating that it only accepts plain files. If it matters,
I'm trying to use that so I can pass a decrypted pgpassfile into postg
Desidero writes:
> I’m running into problems with the restriction on pgpass file types. When
> attempting to use something like an anonymous pipe for a passfile, psql
> throws an error stating that it only accepts plain files.
> ...
> Does anyone know why it’s set up to avoid using things like ano
37 matches
Mail list logo
