On Thu, May 5, 2016 at 2:13 PM, Johann Spies wrote:
> Dankie Arjen,
>
> On 29 April 2016 at 07:01, Arjen Nienhuis wrote:
>
>>
>> > The options I am considering is :
>> >
>> > 1. Unpack the individual records (will be more than 50 million) using
>> > something like python with lxml and psycopg2 an
On Thu, May 05, 2016 at 09:32:28PM -0700, Jeff Janes wrote:
> On Wed, May 4, 2016 at 3:22 PM, Kurt Roeckx wrote:
> > Hi,
> >
> > I have an update query that's been running for 48 hours now.
> > Since it started it used about 2.5% CPU, and is writing to the
> > disk at about 3 MB/s, and reading at
On Fri, May 06, 2016 at 11:38:27AM +0200, Kurt Roeckx wrote:
> On Thu, May 05, 2016 at 09:32:28PM -0700, Jeff Janes wrote:
> > On Wed, May 4, 2016 at 3:22 PM, Kurt Roeckx wrote:
> > > Hi,
> > >
> > > I have an update query that's been running for 48 hours now.
> > > Since it started it used about
drum.lu...@gmail.com wrote:
It's working now...
Final code:
ALTER TABLE public.companies ADD COLUMN client_code_increment integer;
ALTER TABLE public.companies ALTER COLUMN client_code_increment SET NOT
NULL;
ALTER TABLE public.companies ALTER COLUMN client_code_increment SET DEFAU
On 05/05/2016 07:29 PM, rob stone wrote:
Hello Adrian,On Thu, 2016-05-05 at 13:47 -0700, Adrian Klaver wrote:
Exactly. Showing the list the error you get when you cannot connect
help
may with solving that problem and save you a great of time. What
have
you got to lose?
I have nothing to "los
> > It's kind of annoying that I would need to drop the indexes that
> > aren't modified just to run an update query.
>
> I dropped all the index except for the primary key. It was still
> as slow when it started, but then I forced the primary key into
> the filesystem cache and it seems to be
On Fri, May 06, 2016 at 09:13:09AM -0500, Steven Lembark wrote:
>
> > > It's kind of annoying that I would need to drop the indexes that
> > > aren't modified just to run an update query.
> >
> > I dropped all the index except for the primary key. It was still
> > as slow when it started, but
On Fri, May 6, 2016 at 3:21 AM, Kurt Roeckx wrote:
> On Fri, May 06, 2016 at 11:38:27AM +0200, Kurt Roeckx wrote:
>> On Thu, May 05, 2016 at 09:32:28PM -0700, Jeff Janes wrote:
>> > On Wed, May 4, 2016 at 3:22 PM, Kurt Roeckx wrote:
>> > > Hi,
>> > >
>> > > I have an update query that's been runn
On Fri, May 06, 2016 at 10:25:34AM -0700, Jeff Janes wrote:
>
> OK, so it sounds like what is happening is that your update cannot do
> a "Heap-Only Tuple" (HOT) update, because there is not enough room in
> each data page for the new copy of rows being updated. So it is
> forced to put the new c
Le 3 mai 2016 7:01 PM, "Evgeny Morozov"
a écrit :
>
> That's an interesting idea! The client users would use is probably
pgAdmin. I don't know whether pgAdmin parses the query, though. If it does
then it should be relatively easy to add this. If not, I'd imagine it's not
going to happen.
>
The pg
W dniu 04.05.2016 o 22:55, rob stone pisze:
[--]
>
> I can connect via psql and issue queries without any problems. Trying
> to connect via JDBC fails. Trying to connect by an application fails.
>
Since psql works, have you tried the basic tests to figure out the
difference
In a fresh new install of PostgreSQL 9.5.2 on Ubuntu 16.04 I am getting this:
...
Setting up postgresql-9.5 (9.5.2-1.pgdg16.04+1) ...
Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/(?http://www.postgresql.org/mailpref/pgsql-general
12 matches
Mail list logo
