> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Tuan Hoang Anh
> Sent: Tuesday, December 30, 2008 10:49 PM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] How to use index in strpos function
>
> I have ta
I have table command
CREATE TABLE command
(
menuid0 character varying(20) NOT NULL DEFAULT ''::character varying,
menuid character varying(20) NOT NULL DEFAULT ''::character varying,
"text" character varying NOT NULL DEFAULT ''::character varying,
text2 character varying NOT NULL DEFAULT ''::c
"Eric Worden" writes:
> Thank you this helped me fix it. I moved the "create temporary
> table..." statement to the outermost calling function and changed it
> from STABLE to VOLATILE. I'm not sure which change made the
> difference -- I had to move the create table statement for an
> additional
I tried to use the following code to retrieve the content of table1 4
times (in my application, the total number of refcursors that will be
returned is determined by the data in the database). I am getting the
error message says "ERROR: cursor "" already in
use".
Thank you in advance!
dl
--Star
Thank you this helped me fix it. I moved the "create temporary
table..." statement to the outermost calling function and changed it
from STABLE to VOLATILE. I'm not sure which change made the
difference -- I had to move the create table statement for an
additional reason.
On Sat, Dec 27, 2008
Now we are moving closer to 8.4, please join us for testing 8.4 release.
I just released new RPM sets, which is based on Dec 29 2008 CVS
snapshot, which includes Window Functions patch. Please note that these
packages are **not** production ready. They are for Fedora 9 and
RHEL/CentOS 5. I have n
On Tue, Dec 30, 2008 at 10:14 AM, Dan Armbrust
wrote:
>
> On paper, their hardware is plenty fast for their workload. Out of
> hundreds of sites, all running the same software putting load on the
> database, this is only the second time where we have seen this odd
> behaviour of very slow vacuums
>
>> Their workaround had been to run a daily autovacuum at the lowest load
>> time of day, to cause the least disruption.
>
> What is a "daily autovacuum"? It sounds like some tables just need
> vacuuming more often. If they find that the system is not responsive
> during that, it tells us that
On Tue, Dec 30, 2008 at 10:37:04AM -0600, Dan Armbrust wrote:
> The way that they reported the problem to us was that if they enable
> autovacuum, when ever it runs (about 4 times an hour) it would stop
> processing the things it needed to process, due to table lock
> contention for several minute
On Tue, Dec 30, 2008 at 9:32 AM, Dan Armbrust
wrote:
> Haven't looked at that yet on this particular system. Last time, on
> different hardware when this occurred the vmstat 'wa' column showed
> very large values while vacuum was running. I don't recall what the
> bi/bo columns indicated.
defin
On Tue, Dec 30, 2008 at 9:47 AM, Scott Marlowe wrote:
> Keep in mind, hdparm hits the drive directly, not through the
> filesystem. I use bonnie++ or iozone to test io.
Also dd and vmstat together.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
>> INFO: "cpe": found 95498 removable, 18757 nonremovable row versions
>> in 7 pages
>> DETAIL: 0 dead row versions cannot be removed yet.
>> There were 280173 unused item pointers.
>> 0 pages are entirely empty.
>> CPU 5.35s/0.99u sec elapsed 724.38 sec.
>
> How many idle transactions are th
>> INFO: "cpe": found 95498 removable, 18757 nonremovable row versions
>> in 7 pages
>> DETAIL: 0 dead row versions cannot be removed yet.
>> There were 280173 unused item pointers.
>> 0 pages are entirely empty.
>> CPU 5.35s/0.99u sec elapsed 724.38 sec.
>>
>> Then, running vacuum again imme
Hello,
Why do you index a boolean of your condition ?
Isn't it better to have the partial index like the following ?
:
CREATE INDEX i_gm_t_movimenti_magazzini_partial
ON gm_t_movimenti_magazzini( ap_prod_unic )
WHERE gm_moma_flag AND gm_moma_vali>='2008-01-01'::TIMESTAMPTZ;
Hope this helps,
Vi
On Tue, Dec 30, 2008 at 9:10 AM, Dan Armbrust
wrote:
> To follow up on an old thread that I started - I had a customer who
> had a system where manual vacuum runs were taking a very long time to
> run. I was seeing output like this:
>
> INFO: "cpe": found 95498 removable, 18757 nonremovable row
To follow up on an old thread that I started - I had a customer who
had a system where manual vacuum runs were taking a very long time to
run. I was seeing output like this:
INFO: "cpe": found 95498 removable, 18757 nonremovable row versions
in 7 pages
DETAIL: 0 dead row versions cannot be
Here it comes:
-- DDL
CREATE TABLE gm_t_movimenti_magazzini
(
gm_movi_unic INT8 NOT NULL REFERENCES gm_t_movimenti,
gm_moti_unic TEXT NOT NULL REFERENCES gm_t_movimenti_tipi,
ap_prod_unic INT8 NOT NULL REFERENCES ap_t_prodotti,
gm_maga_unic TEXT NOT NULL REFERENCES gm_t_magazzini,
gm_mo
Hello, Albe
In the article you provided it is said that "The return value is the OID
that was assigned to the new large object..." (function Oid
lo_creat(PGconn *conn, int mode);). That means that not the large object
is stored in OID field - its just the reference to it.
Any way I find it muc
dbalinglung wrote:
>> I seriously doubt you could store an image in oid typed column, because
>> "The oid type is currently implemented as an unsigned four-byte
>> integer." (from postgresql 8.2 manual). I too use Zeos with no problems
>> using bytea type.
>
> Ok, I'll try your sugestion, many t
Reg Me Please wrote:
Only one question remains in my mind:
why the planner is not using the partial index?
The partial index is covering 2 predicates out of the 3 used in the where
condition. Actually there is a boolean flag (to exclude "disabled" rows),
a timestamp (for row age) and an int
On Tue, Dec 30, 2008 at 2:02 AM, Reg Me Please wrote:
> Only one question remains in my mind:
>
> why the planner is not using the partial index?
>
> The partial index is covering 2 predicates out of the 3 used in the where
> condition. Actually there is a boolean flag (to exclude "disabled" rows)
Hi All,
We were getting the following error on executing a COPY command on
postgres8.2.0.
SQL execution failed, Internal error. SQL Statement: (COPY command
failed with error: ERROR: row is too big: size 8200, maximum size 8136)
So, in order to fix the error we tried increasing the block size t
Ok, I'll try your sugestion, many thanks bro.
Regards,
dbalinglung
>- Original Message -
>From: "Julius Tuskenis"
>To: "dbalinglung"
>Sent: Tuesday, December 30, 2008 5:39 PM
>Subject: Re: [GENERAL] Load Image File From PostgreSQL DB
>
>I seriously doubt you could store an image in
Hi2 Julius,
Thanks for your reply, present i using oid data type for store image file, and
good working without problem too if i open and showing with PHP, but i'm verry
dificulty to showing the image file using delphi 7.
also i'm not using third party like ODBC but i'm directly connected to
P
Hi,
I am using Delphi 2007 and turining property active false/true on
table/query component will refresh the component (and its fields). If you
are really using this query to drop columns of a table, then you shouldn't
add the fields of the table in the query component. After dropping a column
Only one question remains in my mind:
why the planner is not using the partial index?
The partial index is covering 2 predicates out of the 3 used in the where
condition. Actually there is a boolean flag (to exclude "disabled" rows),
a timestamp (for row age) and an int8 (a FK to another table).
Filip Rembiałkowski wrote:
create table table1 (
key1 char(12),
key2 integer,
primary key (key1, key2)
);
create table table2 (
key1 char(12),
key2 integer,
key3 varchar(20),
primary key (key1, key2, key3),
27 matches
Mail list logo
