hiroyuki shiga writes:
> I'm having problems postgesql coredump.
> Do you have any idea?.
Can you provide a self-contained test case that causes that?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
Hello again,
I have been digging a bit more into this and I have seen that the increase
of the table size is not caused by the index, but by the data storage to
disk implementation. As it is explained at the documentation of
pg_largeobject (
http://www.postgresql.org/docs/9.2/static/catalog-pg-lar
Jesse Long wrote:
> I did ALTER COLUMN SET STATISTICS 1 for each column involved after
> that (is that what you meant?). But it did not make much difference, but
> I have read the manual regarding this setting and think I understand it.
>
> Would it be a bad idea to ALTER COLUMN SET STATISTICS
Thank you for reply.
but I can't provide a self-contained test case.
2013/10/11 Tom Lane
> hiroyuki shiga writes:
> > I'm having problems postgesql coredump.
> > Do you have any idea?.
>
> Can you provide a self-contained test case that causes that?
>
> regards, t
> I have developed an application using MS SQL. I have used MS Access
> for creating forms to enter data into the database. I am thinking of
> changing over to postgresql and would also like to use any other
> available open source tool for creating forms. Are there any free
> applications availabl
> Forms these days are written in HTML.
Only by clueless/careless morons.
HTML has never been, is not and will never be a usable GUI framework.
And "web apps" are unusable garbage.
Sincerely,
Wolfgang
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
- Original Message -
From: "Wolfgang Keller"
To: pgsql-general@postgresql.org
Sent: Friday, October 11, 2013 1:45:10 PM
Subject: Re: [GENERAL] Forms for entering data into postgresql
> I have developed an application using MS SQL. I have used MS Access
> for creating forms to enter data
Try Libreoffice Base
Thanks,
Sunday Olutayo
- Original Message -
From: "Wolfgang Keller"
To: pgsql-general@postgresql.org
Sent: Friday, October 11, 2013 1:45:10 PM
Subject: Re: [GENERAL] Forms for entering data into postgresql
> I have developed an application using MS SQL. I have
Forgot to reply to list. Sorry. Perhaps somebody here knows of an
"array_reverse" type function.
-- Forwarded message --
From: John McKown
Date: Fri, Oct 11, 2013 at 7:53 AM
Subject: Re: [GENERAL] String reverse funtion?
To: ginkgo36
I don't see one. Looks like you will need to
On 09/10/2013 18:06, Tom Lane wrote:
Jesse Long writes:
The query runs for much longer than I expect it to run for, and I think
this is due to it using the incorrect subplan. As you can see, subplans
1 and 3 make use of and index, but these subplans are not used.
Subplans and 4 are seqscan, an
On Fri, Oct 11, 2013 at 7:47 AM, Wolfgang Keller wrote:
>> Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.
Look -- I appreciate people with strong unortho
On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
Thank you for reply.
but I can't provide a self-contained test case.
So what are you doing when you get the core dump?
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Adrian Klaver escribió:
> On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
> >Thank you for reply.
> >
> >but I can't provide a self-contained test case.
> >
>
> So what are you doing when you get the core dump?
The query is in the backtrace:
SELECT PATH, COUNT(SITE_ID)
FROM ACCESS_LOG_05
WHER
With a brief look at the last 15 years of programming for the web, your
comments are a little harsh. Only a short time ago perl and cgi
was the rage.
I've been programming for 30 years...and still have clients who use
Lotus 123 (MS-DOS) based. It's a big world out there, and lots of
solutionsf
My interpretation of "Forms these days are written in HTML" means
most interfaces are web front ends to the cloud. Not a GUI framework.
On Fri, 2013-10-11 at 14:47 +0200, Wolfgang Keller wrote:
> > Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never bee
On Oct 11, 2013, at 8:57 AM, Bret Stern
wrote:
> My interpretation of "Forms these days are written in HTML" means
> most interfaces are web front ends to the cloud. Not a GUI framework.
Yup.
But embedding an HTML renderer in your desktop app does allow you to
use HTML where it's appropriate
Agreed.
On Fri, 2013-10-11 at 09:06 -0700, Steve Atkins wrote:
> On Oct 11, 2013, at 8:57 AM, Bret Stern
> wrote:
>
> > My interpretation of "Forms these days are written in HTML" means
> > most interfaces are web front ends to the cloud. Not a GUI framework.
>
>
> Yup.
>
> But embedding an H
We have 4 applications ( 2 transactional , 2 ( transactional + reporting ))
on postgres 32 bit 9.0.4
Some of the queries are extreemly taking time ( 10 seconds). I can the
explain for that also.
I just want to get your thoughts on the conf file values we have are good.
Really appreciate your help
On 12/10/13 05:06, Steve Atkins wrote:
On Oct 11, 2013, at 8:57 AM, Bret Stern
wrote:
My interpretation of "Forms these days are written in HTML" means
most interfaces are web front ends to the cloud. Not a GUI framework.
Yup.
But embedding an HTML renderer in your desktop app does allow y
Wolfgang Keller-2 wrote
>> Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.
Yet you have not stated what it is that you find works better.
Lots of softw
On 10/11/2013 08:36 AM, Alvaro Herrera wrote:
Adrian Klaver escribió:
On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
Thank you for reply.
but I can't provide a self-contained test case.
So what are you doing when you get the core dump?
The query is in the backtrace:
SELECT PATH, COUN
On 10/11/2013 08:56 AM, akp geek wrote:
We have been running 4 of our applications on 9.0.4, which we are
planning to update the database 9.2.2 by the year end
Sorry if I missed it but I couldn't find a question or description of a
problem you are encountering.
Cheers,
Steve
--
Sent v
On 10/11/2013 9:34 AM, akp geek wrote:
thanks for the help
whats the question?you list what you're doing, and give a snapshot
of your system state while doing some unspecified tasks.
--
john r pierce 37N 122W
somewhere on the middle of the left coas
On 10/11/2013 8:56 AM, akp geek wrote:
We have been running 4 of our applications on 9.0.4, which we are
planning to update the database 9.2.2
9.0 is currently at 9.0.14, and 9.2 is currently at 9.2.5.
--
john r pierce 37N 122W
somewhere on the middle of
On Fri, Oct 11, 2013 at 3:51 AM, hiroyuki shiga wrote:
> Thank you for reply.
>
> but I can't provide a self-contained test case.
>
It that because it is too proprietary/sensitive to provide, or because the
problem is not readily reproducible?
Cheers,
Jeff
On 10/11/2013 3:51 AM, hiroyuki shiga wrote:
but I can't provide a self-contained test case.
what were you doing when this coredump occured?
did any errors get logged by the postgresql server? kernel?
what platform (operating system, version, bitsize, etc) are you running on?
a stack tr
On Fri, Oct 11, 2013 at 10:08 AM, akp geek wrote:
> We have 4 applications ( 2 transactional , 2 ( transactional + reporting ))
> on postgres 32 bit 9.0.4
>
> Some of the queries are extreemly taking time ( 10 seconds). I can the
> explain for that also.
>
> I just want to get your thoughts on the
On Fri, Oct 11, 2013 at 9:32 AM, Jesse Long wrote:
> explain select * from archive_document_index where node_id = 29 and value
> = 'BSH70002152';
> QUERY PLAN
> --**--**
> -
28 matches
Mail list logo
