17.Tem.2010 tarihinde 22:54 saatinde, Tom Lane
şunları yazdı:
Jerry LeVan writes:
On Jul 17, 2010, at 1:21 PM, Tom Lane wrote:
Uhm ... what's wrong with the Fedora-supplied PG RPMs?
For a long time Fedora rpms lagged the rpms that Devrim made for
the yum repository.
Well, I'm not al
Jerry LeVan writes:
> On Jul 17, 2010, at 1:21 PM, Tom Lane wrote:
>> Uhm ... what's wrong with the Fedora-supplied PG RPMs?
> For a long time Fedora rpms lagged the rpms that Devrim made for
> the yum repository.
Well, I'm not allowed to bump to a new major PG version within a
stable Fedora rel
On Jul 17, 2010, at 1:21 PM, Tom Lane wrote:
> Jerry LeVan writes:
>> I wish whoever is in charge of the yum rpm depository would get
>> cracking on building the Fedora 13 repo...
>
> Uhm ... what's wrong with the Fedora-supplied PG RPMs?
>
> regards, tom lane
For a long
Tom Lane wrote on 17.07.2010 19:35:
Thomas Kellerer writes:
Tom Lane wrote on 17.07.2010 16:36:
Well, nobody's offered any actual *numbers* here.
I measured the runtime as seen from the JDBC client and as reported by explain analyze
(the last line reading "Total runtime:")
The "runtime"
Thomas Kellerer writes:
> Tom Lane wrote on 17.07.2010 16:36:
>> Well, nobody's offered any actual *numbers* here.
> I measured the runtime as seen from the JDBC client and as reported by
> explain analyze (the last line reading "Total runtime:")
The "runtime" from explain analyze really should
Jerry LeVan writes:
> I wish whoever is in charge of the yum rpm depository would get
> cracking on building the Fedora 13 repo...
Uhm ... what's wrong with the Fedora-supplied PG RPMs?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
Thomas Kellerer wrote on 17.07.2010 18:29:
Want to do some experiments?
Apparently there *is* a substiantial overhead, but I suspected the
sending of the raw SQL literal to be a major factor here.
(Server and JDBC program were running on the same machine)
In case any one is interested.
Out
Tom Lane wrote on 17.07.2010 16:36:
Thomas Kellerer writes:
I'm till a bit surprised that parsing the statement _with_ a column list is
mesurably slower than withou a column list.
Well, nobody's offered any actual *numbers* here. It's clear that
parsing the column list will take more time t
Order contains same product in multiple rows.
I tried to calculate undelivered quantity using script below but it produces
wrong result:
delivered quantity is substracted from both rows, not distributed.
How to distibute undelivered quantity according to row quantity in every row
?
Can it be done
On Sat, 2010-07-17 at 08:49 -0700, Joe Conway wrote:
> On 07/17/2010 08:12 AM, Tom Lane wrote:
> > I wrote:
> > Oh, and Theory 3: see if restarting your postgresql server fixes it.
> > If you didn't restart then the old openldap libraries are probably
> > still in the server's address space. I'm n
On 07/17/2010 08:12 AM, Tom Lane wrote:
> I wrote:
> Oh, and Theory 3: see if restarting your postgresql server fixes it.
> If you didn't restart then the old openldap libraries are probably
> still in the server's address space. I'm not sure exactly how that
> might lead to this symptom, but it s
On Thu, Jul 15, 2010 at 10:21:52AM -0400, Merlin Moncure wrote:
> On Thu, Jul 15, 2010 at 2:34 AM, tamanna madaan
> wrote:
> > Hi All
> >
> > I am using postgres-8.1.2 .
> >
> > And getting this error “cache lookup failed for function 19119”.
> >
> > Can anyone please let me know what could have
I wrote:
> Theory 2: this week's F-13 update to openldap misfired on your box.
> (If so, forcibly removing and reinstalling openldap might fix it.)
Oh, and Theory 3: see if restarting your postgresql server fixes it.
If you didn't restart then the old openldap libraries are probably
still in the s
Jerry LeVan writes:
> I think that something bad has happened to Fedora 13 this week.
> This morning when I tried the following:
> select dblink_connect('host=mbp user=levan dbname=levan password=xx')
> I got the following error:
> Error: could not load library "/usr/lib/pgsql/dblink.so":
Thomas Kellerer writes:
> I'm till a bit surprised that parsing the statement _with_ a column list is
> mesurably slower than withou a column list.
Well, nobody's offered any actual *numbers* here. It's clear that
parsing the column list will take more time than not doing so, but
whether that a
On Saturday 17. July 2010 15.14.51 Cornelio Royer Climent wrote:
>
> Hi
>
>
>
> I want to create this table, but i can't,
>
>
>
> Look this error.
>
>
>
>
>
> CREATE TABLE security_info2 (
>
> window character varying(64) NOT NULL
>
> );
>
> ERROR: syntax error at or near "
Hi
I want to create this table, but i can't,
Look this error.
CREATE TABLE security_info2 (
window character varying(64) NOT NULL
);
ERROR: syntax error at or near "window"
LINE 2: window character varying(64) NOT NULL
Could any to help me, please?
I'm
17.Tem.2010 tarihinde 16:10 saatinde, Jerry LeVan
şunları yazdı:
I think that something bad has happened to Fedora 13 this week.
This morning when I tried the following:
select dblink_connect('host=mbp user=levan dbname=levan
password=xx')
I got the following error:
Error: could no
On 17/07/2010 14:16, Cornelio Royer Climent wrote:
CREATE TABLE security_info2 (
window character varying(64) NOT NULL
);
ERROR: syntax error at or near "window"
LINE 2: window character varying(64) NOT NULL
"window" is a reserved word:
http://www.postgresql.org/docs/8.4/static/sql-keyw
Hi
I want to create this table, but i can't,
Look this error.
CREATE TABLE security_info2 (
window character varying(64) NOT NULL
);
ERROR: syntax error at or near "window"
LINE 2: window character varying(64) NOT NULL
Could any to help me, please?
I'm using postgresql 8.4
I think that something bad has happened to Fedora 13 this week.
This morning when I tried the following:
select dblink_connect('host=mbp user=levan dbname=levan password=xx')
I got the following error:
Error: could not load library "/usr/lib/pgsql/dblink.so":
/usr/lib/libldap_r-2.4.so.2: u
Artur,
I downloaded your dump and tried your queries with index, I see no problem
so far.
Table "public.search_tab"
Column | Type |Modifiers
+-+--
Craig Ringer wrote on 17.07.2010 03:13:
On 17/07/10 04:26, Thomas Kellerer wrote:
Hmm.
For years I have been advocating to always use fully qualified column
lists in INSERTs (for clarity and stability)
And now I learn it's slower when I do so :(
If you're not doing hundreds of thousands of id
Joshua Rubin wrote:
> I need to figure out why this is slow, and if there is any faster way.
Have you considered INSERTing into a third table that would replace both
source tables when it's over? The target table would initially have no index.
Best regards,
--
Daniel
PostgreSQL-powered
24 matches
Mail list logo
