Friday, September 26, 2008

Re: [GENERAL] Is there any way to reliably influence WHERE predicate evaluation ordering?

Decibel! <decibel@decibel.org> writes:
> Does anyone have any ideas on a clean and reliable way to do this?

Use a trigger.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] postgres at reboot

Hi Scott,

It's too bad (in this particular case) that you are
agreeing with me!  I want someone to find a hole in
my logic so that I can find a handle to fix the
problem.  The problem being that postgres doesn't get
started when the machine gets rebooted.

Regards,

Tena Sakai
tsakai@gallo.ucsf.edu


-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: Fri 9/26/2008 1:44 PM
To: Tena Sakai
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] postgres at reboot

On Fri, Sep 26, 2008 at 2:38 PM, Tena Sakai <tsakai@gallo.ucsf.edu> wrote:
> Hi Scott,
>
> When I issue: /sbin/chkconfig --list | grep postgres
> it comes back with:
>
>  postgresql_ORG  0:off   1:off   2:off   3:off   4:off   5:off   6:off
>  postgresql      0:off   1:off   2:on    3:on    4:on    5:on    6:off
>
> I felt a bit strange that it says 'off' at run level 6.

Run level 6 is reboot, so that's normal.

> I went into /etc/rc.d and issued:
>  sudo find . -name \*postgresql\* -ls | grep S98postgresql
> and it came back with:
>
>  15618186    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00
> ./rc4.d/S98postgresql -> ../init.d/postgresql
>  15618294    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00
> ./rc3.d/S98postgresql -> ../init.d/postgresql
>  15618351    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00
> ./rc2.d/S98postgresql -> ../init.d/postgresql
>  15618024    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00
> ./rc5.d/S98postgresql -> ../init.d/postgresql
>
> Next, I went into /etc/rc.d/rc6.d and typed:
>  ls -l
> and it gave me this:
>      .       .  .    .      .  .   .   .         .              .        .
>      .       .  .    .      .  .   .   .         .              .        .
> lrwxrwxrwx   1 root root   20 Aug 21 17:00 S98postgresq ->
> ../init.d/postgresql
>
> There is an 'l' missing from the name!  I thought for a moment

It shouldn't  be there, sounds like someone added it by hand.

> I found the culprit, but then I issued the command below:
>  /sbin/chkconfig --list | grep '6:on'
> and it returned nothing.
>
> I am a bit confused.  As I understand, run level 6 means, in
> redhat context, shutdown and reboot.  But it seems in my case
> nothing is turned on for level 6.  Then that missing 'l'
> is really of no significance?

Right, nothing should be started for those run levels.

Re: [HACKERS] parallel pg_restore - WIP patch

Stefan Kaltenbrunner wrote:
> Andrew Dunstan wrote:
>>
>>
>> This version of the patch should fix the "shared file descriptor" bug
>> Russell Smith noticed. It also disables the 1/2 second sleep between
>> forks, so the performance on a small db (regression) is vastly improved.
>
> this works better but there is something fishy still - using the same
> dump file I get a proper restore using pg_restore normally. If I
> however use -m for a parallel one I only get parts (in this case only
> 243 of the 709 tables) of the database restored ...
>
>
>

Yes, there are several funny things going on, including some stuff with
dependencies. I'll have a new patch tomorrow with luck. Thanks for testing.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore - WIP patch

Andrew Dunstan wrote:
>
>
> This version of the patch should fix the "shared file descriptor" bug
> Russell Smith noticed. It also disables the 1/2 second sleep between
> forks, so the performance on a small db (regression) is vastly improved.

this works better but there is something fishy still - using the same
dump file I get a proper restore using pg_restore normally. If I however
use -m for a parallel one I only get parts (in this case only 243 of the
709 tables) of the database restored ...


Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Consulta plpgsql

copio a la lista
> la sentencia de las temp es:
>
> select * into temporary temp from (......)
>
> saludos
>
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [ADMIN] postgres at reboot

On Fri, Sep 26, 2008 at 2:38 PM, Tena Sakai <tsakai@gallo.ucsf.edu> wrote:
> Hi Scott,
>
> When I issue: /sbin/chkconfig --list | grep postgres
> it comes back with:
>
> postgresql_ORG 0:off 1:off 2:off 3:off 4:off 5:off 6:off
> postgresql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
>
> I felt a bit strange that it says 'off' at run level 6.

Run level 6 is reboot, so that's normal.

> I went into /etc/rc.d and issued:
> sudo find . -name \*postgresql\* -ls | grep S98postgresql
> and it came back with:
>
> 15618186 0 lrwxrwxrwx 1 root root 20 Aug 21 17:00
> ./rc4.d/S98postgresql -> ../init.d/postgresql
> 15618294 0 lrwxrwxrwx 1 root root 20 Aug 21 17:00
> ./rc3.d/S98postgresql -> ../init.d/postgresql
> 15618351 0 lrwxrwxrwx 1 root root 20 Aug 21 17:00
> ./rc2.d/S98postgresql -> ../init.d/postgresql
> 15618024 0 lrwxrwxrwx 1 root root 20 Aug 21 17:00
> ./rc5.d/S98postgresql -> ../init.d/postgresql
>
> Next, I went into /etc/rc.d/rc6.d and typed:
> ls -l
> and it gave me this:
> . . . . . . . . . . .
> . . . . . . . . . . .
> lrwxrwxrwx 1 root root 20 Aug 21 17:00 S98postgresq ->
> ../init.d/postgresql
>
> There is an 'l' missing from the name! I thought for a moment

It shouldn't be there, sounds like someone added it by hand.

> I found the culprit, but then I issued the command below:
> /sbin/chkconfig --list | grep '6:on'
> and it returned nothing.
>
> I am a bit confused. As I understand, run level 6 means, in
> redhat context, shutdown and reboot. But it seems in my case
> nothing is turned on for level 6. Then that missing 'l'
> is really of no significance?

Right, nothing should be started for those run levels.

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [pgsql-es-ayuda] Difundamos el uso de PostgreSQL

Quedo muy copado!!
Gracias!
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

Re: [GENERAL] dynamic sql in PL-Pgsql ?

On 26/09/2008 21:19, Gauthier, Dave wrote:
> As you can see, the select statement needs to be dynamic in that the
> column name is stored in a variable.
>
>
> Can this be done?

http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN


------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] postgres at reboot

Hi Scott,

When I issue: /sbin/chkconfig --list | grep postgres
it comes back with:

 postgresql_ORG  0:off   1:off   2:off   3:off   4:off   5:off   6:off
 postgresql      0:off   1:off   2:on    3:on    4:on    5:on    6:off

I felt a bit strange that it says 'off' at run level 6.
I went into /etc/rc.d and issued:
 sudo find . -name \*postgresql\* -ls | grep S98postgresql
and it came back with:

 15618186    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00 ./rc4.d/S98postgresql -> ../init.d/postgresql
 15618294    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00 ./rc3.d/S98postgresql -> ../init.d/postgresql
 15618351    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00 ./rc2.d/S98postgresql -> ../init.d/postgresql
 15618024    0 lrwxrwxrwx   1 root     root           20 Aug 21 17:00 ./rc5.d/S98postgresql -> ../init.d/postgresql

Next, I went into /etc/rc.d/rc6.d and typed:
 ls -l
and it gave me this:
     .       .  .    .      .  .   .   .         .              .        .
     .       .  .    .      .  .   .   .         .              .        .
lrwxrwxrwx   1 root root   20 Aug 21 17:00 S98postgresq -> ../init.d/postgresql

There is an 'l' missing from the name!  I thought for a moment
I found the culprit, but then I issued the command below:
 /sbin/chkconfig --list | grep '6:on'
and it returned nothing.

I am a bit confused.  As I understand, run level 6 means, in
redhat context, shutdown and reboot.  But it seems in my case
nothing is turned on for level 6.  Then that missing 'l'
is really of no significance?

Any thoughts?  Clues?

Regards,

Tena Sakai
tsakai@gallo.ucsf.edu



-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: Thu 9/25/2008 12:46 PM
To: Tena Sakai
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] postgres at reboot

On Thu, Sep 25, 2008 at 1:42 PM, Tena Sakai <tsakai@gallo.ucsf.edu> wrote:
> Hi Everybody,
>
> About 1.5 month ago, my machine (which runs redhat linux
> 2.6.9-78.0.1.ELsmp on Dell hardware with postgres 8.3.3)
> had a terrible crash.  I am mostly recovered, but there
> is at least one more thing that's not right.
>
> Namely, when the machine gets rebooted, postgres doesn't
> start automatically.  Before the crash, there was no such
> problem.

In RH, you use chkconfig to see what's set to start:

chkconfig --list

will show you all the services and what run levels they come up in.

chkconfig servicename on|off -- will turn a service on or off at boot.

service servicename start -- will start a service.

Re: [pgsql-advocacy] [Pgday-organize] [Fwd: Re: pgConf latin america]



On Fri, Sep 26, 2008 at 12:07 PM, Josh Berkus <josh@agliodbs.com> wrote:

> how can I get sponsorship for the realization of a possible event
> postgresql for Latin America.??

Hi Ricardo,

What do you have in mind?  Please let us know what/where/how/when.

I recently visited Mexico City and would love to go back :)

-selena


--
Selena Deckelmann
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

[GENERAL] dynamic sql in PL-Pgsql ?

Hi:

 

I want to do something like this.....

 

 

create or replace function foo(varchar, varchar) returns integer as $$

declare

  user_attrib   alias for $1;

  attrib_val    alias for $2;

  rec record;

 

begin

 

  for rec in

    select name from people_table where user_attrib = attrib_value

  loop

     insert into my_temp_table (attrib, value, name) values (user_attrib, attrib_value, rec.name);

  end loop;

 

end;

$$ language plpgsql;

 

As you can see, the select statement needs to be dynamic in that the column name is stored in a variable.

 

Can this be done?

 

Thanks

-dave

 

 

 

 

 

 

 

Re: [HACKERS] About the parameter of API: PQprepared

Merlin Moncure wrote:
> On Fri, Sep 26, 2008 at 2:45 AM, iihero <iihero@gmail.com> wrote:
>> In libpq, the definition is like:
>> PGresult *
>> PQprepare(PGconn *conn,
>> const char *stmtName, const char *query,
>> int nParams, const Oid *paramTypes)
>>
>> Could we remove the parameter "nParams"?
>> e.g. "insert into foo(id, name, address) values ($1, $2, $3)"
>> PostgreSQL possibly can parse the prepared sql statement to get the real
>> paramters count.
>>
>> Or, is there another alternate way?
>
> if you are looking for easier way to do things like prepared
> statements, etc. over libpq, you may want to look at libpqtypes (it's
> a external library that will require a patched libpq for versions
> <8.4):
>
> http://libpqtypes.esilo.com/
>
> merlin
>

Sounds like you could make use of libpqtypes, which abstracts you from
the standard parameterized API.

Latest version of libpqtypes is finally online (v1.2a):

http://pgfoundry.org/frs/?group_id=1000370

NOTE: requires using cvs head because libpqtypes needs the new
libpq-events feature.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] lock contention on parallel COPY ?

Index: src/backend/access/heap/heapam.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/heap/heapam.c,v
retrieving revision 1.263
diff -c -r1.263 heapam.c
*** src/backend/access/heap/heapam.c 11 Sep 2008 14:01:09 -0000 1.263
--- src/backend/access/heap/heapam.c 26 Sep 2008 19:16:27 -0000
***************
*** 1728,1733 ****
--- 1728,1748 ----
}
}

+ /*
+ * Begin/End Bulk Inserts
+ *
+ */
+ void
+ heap_begin_bulk_insert(void)
+ {
+ ReleaseBulkInsertBufferIfAny();
+ }
+
+ void
+ heap_end_bulk_insert(void)
+ {
+ ReleaseBulkInsertBufferIfAny();
+ }

/*
* heap_insert - insert tuple into a heap
***************
*** 1755,1765 ****
*/
Oid
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm)
{
TransactionId xid = GetCurrentTransactionId();
HeapTuple heaptup;
Buffer buffer;

if (relation->rd_rel->relhasoids)
{
--- 1770,1781 ----
*/
Oid
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm, bool bulk_insert_request)
{
TransactionId xid = GetCurrentTransactionId();
HeapTuple heaptup;
Buffer buffer;
+ bool bulk_insert = bulk_insert_request && !relation->rd_istemp;

if (relation->rd_rel->relhasoids)
{
***************
*** 1812,1820 ****
else
heaptup = tup;

! /* Find buffer to insert this tuple into */
! buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
! InvalidBuffer, use_fsm);

/* NO EREPORT(ERROR) from here till changes are logged */
START_CRIT_SECTION();
--- 1828,1845 ----
else
heaptup = tup;

! /*
! * Find buffer to insert this tuple into
! */
! if (bulk_insert)
! {
! buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
! GetBulkInsertBuffer(), use_fsm, true);
! SetBulkInsertBuffer(buffer);
! }
! else
! buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
! InvalidBuffer, use_fsm, false);

/* NO EREPORT(ERROR) from here till changes are logged */
START_CRIT_SECTION();
***************
*** 1893,1899 ****

END_CRIT_SECTION();

! UnlockReleaseBuffer(buffer);

/*
* If tuple is cachable, mark it for invalidation from the caches in case
--- 1918,1930 ----

END_CRIT_SECTION();

! /*
! * Keep buffer pinned if we are in bulk insert mode
! */
! if (bulk_insert)
! LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
! else
! UnlockReleaseBuffer(buffer);

/*
* If tuple is cachable, mark it for invalidation from the caches in case
***************
*** 1930,1936 ****
Oid
simple_heap_insert(Relation relation, HeapTuple tup)
{
! return heap_insert(relation, tup, GetCurrentCommandId(true), true, true);
}

/*
--- 1961,1967 ----
Oid
simple_heap_insert(Relation relation, HeapTuple tup)
{
! return heap_insert(relation, tup, GetCurrentCommandId(true), true, true, false);
}

/*
***************
*** 2553,2559 ****
{
/* Assume there's no chance to put heaptup on same page. */
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
! buffer, true);
}
else
{
--- 2584,2590 ----
{
/* Assume there's no chance to put heaptup on same page. */
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
! buffer, true, false);
}
else
{
***************
*** 2570,2576 ****
*/
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
! buffer, true);
}
else
{
--- 2601,2607 ----
*/
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
! buffer, true, false);
}
else
{
Index: src/backend/access/heap/hio.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/heap/hio.c,v
retrieving revision 1.72
diff -c -r1.72 hio.c
*** src/backend/access/heap/hio.c 13 Jul 2008 20:45:47 -0000 1.72
--- src/backend/access/heap/hio.c 26 Sep 2008 19:16:27 -0000
***************
*** 104,110 ****
*/
Buffer
RelationGetBufferForTuple(Relation relation, Size len,
! Buffer otherBuffer, bool use_fsm)
{
Buffer buffer = InvalidBuffer;
Page page;
--- 104,110 ----
*/
Buffer
RelationGetBufferForTuple(Relation relation, Size len,
! Buffer otherBuffer, bool use_fsm, bool bulk_insert)
{
Buffer buffer = InvalidBuffer;
Page page;
***************
*** 199,217 ****
buffer = otherBuffer;
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
}
! else if (otherBlock < targetBlock)
{
! /* lock other buffer first */
buffer = ReadBuffer(relation, targetBlock);
- LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
}
! else
{
! /* lock target buffer first */
! buffer = ReadBuffer(relation, targetBlock);
! LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
! LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
}

/*
--- 199,226 ----
buffer = otherBuffer;
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
}
! else if (bulk_insert)
{
! ReleaseBuffer(otherBuffer);
buffer = ReadBuffer(relation, targetBlock);
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
}
! else if (!bulk_insert)
{
! if (otherBlock < targetBlock)
! {
! /* lock other buffer first */
! buffer = ReadBuffer(relation, targetBlock);
! LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
! LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
! }
! else
! {
! /* lock target buffer first */
! buffer = ReadBuffer(relation, targetBlock);
! LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
! LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
! }
}

/*
***************
*** 266,271 ****
--- 275,283 ----
*/
needLock = !RELATION_IS_LOCAL(relation);

+ if (bulk_insert && otherBuffer != InvalidBuffer)
+ ReleaseBuffer(otherBuffer);
+
if (needLock)
LockRelationForExtension(relation, ExclusiveLock);

***************
*** 281,287 ****
* We can be certain that locking the otherBuffer first is OK, since it
* must have a lower page number.
*/
! if (otherBuffer != InvalidBuffer)
LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);

/*
--- 293,299 ----
* We can be certain that locking the otherBuffer first is OK, since it
* must have a lower page number.
*/
! if (!bulk_insert && otherBuffer != InvalidBuffer)
LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);

/*
Index: src/backend/access/heap/tuptoaster.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/heap/tuptoaster.c,v
retrieving revision 1.89
diff -c -r1.89 tuptoaster.c
*** src/backend/access/heap/tuptoaster.c 19 Jun 2008 00:46:03 -0000 1.89
--- src/backend/access/heap/tuptoaster.c 26 Sep 2008 19:16:27 -0000
***************
*** 1218,1224 ****
memcpy(VARDATA(&chunk_data), data_p, chunk_size);
toasttup = heap_form_tuple(toasttupDesc, t_values, t_isnull);

! heap_insert(toastrel, toasttup, mycid, use_wal, use_fsm);

/*
* Create the index entry. We cheat a little here by not using
--- 1218,1224 ----
memcpy(VARDATA(&chunk_data), data_p, chunk_size);
toasttup = heap_form_tuple(toasttupDesc, t_values, t_isnull);

! heap_insert(toastrel, toasttup, mycid, use_wal, use_fsm, false);

/*
* Create the index entry. We cheat a little here by not using
Index: src/backend/access/transam/xact.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.265
diff -c -r1.265 xact.c
*** src/backend/access/transam/xact.c 11 Aug 2008 11:05:10 -0000 1.265
--- src/backend/access/transam/xact.c 26 Sep 2008 19:16:27 -0000
***************
*** 2105,2110 ****
--- 2105,2111 ----
RESOURCE_RELEASE_BEFORE_LOCKS,
false, true);
AtEOXact_Buffers(false);
+ AtEOXact_BulkInsert();
AtEOXact_RelationCache(false);
AtEOXact_Inval(false);
smgrDoPendingDeletes(false);
***************
*** 3941,3946 ****
--- 3942,3948 ----
ResourceOwnerRelease(s->curTransactionOwner,
RESOURCE_RELEASE_BEFORE_LOCKS,
false, false);
+ AtEOXact_BulkInsert();
AtEOSubXact_RelationCache(false, s->subTransactionId,
s->parent->subTransactionId);
AtEOSubXact_Inval(false);
Index: src/backend/commands/copy.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.299
diff -c -r1.299 copy.c
*** src/backend/commands/copy.c 12 May 2008 20:01:59 -0000 1.299
--- src/backend/commands/copy.c 26 Sep 2008 19:16:27 -0000
***************
*** 1655,1660 ****
--- 1655,1661 ----
CommandId mycid = GetCurrentCommandId(true);
bool use_wal = true; /* by default, use WAL logging */
bool use_fsm = true; /* by default, use FSM for free space */
+ bool bulk_insert = true; /* by default, use bulk inserts */

Assert(cstate->rel);

***************
*** 1899,1904 ****
--- 1900,1908 ----
done = CopyReadLine(cstate);
}

+ if (bulk_insert)
+ heap_begin_bulk_insert();
+
while (!done)
{
bool skip_tuple;
***************
*** 2111,2117 ****
ExecConstraints(resultRelInfo, slot, estate);

/* OK, store the tuple and create index entries for it */
! heap_insert(cstate->rel, tuple, mycid, use_wal, use_fsm);

if (resultRelInfo->ri_NumIndices > 0)
ExecInsertIndexTuples(slot, &(tuple->t_self), estate, false);
--- 2115,2121 ----
ExecConstraints(resultRelInfo, slot, estate);

/* OK, store the tuple and create index entries for it */
! heap_insert(cstate->rel, tuple, mycid, use_wal, use_fsm, bulk_insert);

if (resultRelInfo->ri_NumIndices > 0)
ExecInsertIndexTuples(slot, &(tuple->t_self), estate, false);
***************
*** 2128,2133 ****
--- 2132,2140 ----
}
}

+ if (bulk_insert)
+ heap_end_bulk_insert();
+
/* Done, clean up */
error_context_stack = errcontext.previous;

Index: src/backend/executor/execMain.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/executor/execMain.c,v
retrieving revision 1.313
diff -c -r1.313 execMain.c
*** src/backend/executor/execMain.c 25 Aug 2008 22:42:32 -0000 1.313
--- src/backend/executor/execMain.c 26 Sep 2008 19:18:27 -0000
***************
*** 1648,1654 ****
*/
newId = heap_insert(resultRelationDesc, tuple,
estate->es_output_cid,
! true, true);

IncrAppended();
(estate->es_processed)++;
--- 1648,1654 ----
*/
newId = heap_insert(resultRelationDesc, tuple,
estate->es_output_cid,
! true, true, false);

IncrAppended();
(estate->es_processed)++;
***************
*** 2837,2843 ****
static void
intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
{
! /* no-op */
}

/*
--- 2837,2843 ----
static void
intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
{
! heap_begin_bulk_insert();
}

/*
***************
*** 2859,2865 ****
tuple,
myState->estate->es_output_cid,
myState->use_wal,
! false); /* never any point in using FSM */

/* We know this is a newly created relation, so there are no indexes */

--- 2859,2866 ----
tuple,
myState->estate->es_output_cid,
myState->use_wal,
! false, /* never any point in using FSM */
! true); /* always run a bulk insert */

/* We know this is a newly created relation, so there are no indexes */

***************
*** 2872,2878 ****
static void
intorel_shutdown(DestReceiver *self)
{
! /* no-op */
}

/*
--- 2873,2879 ----
static void
intorel_shutdown(DestReceiver *self)
{
! heap_end_bulk_insert();
}

/*
Index: src/backend/storage/buffer/bufmgr.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.238
diff -c -r1.238 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 17 Sep 2008 13:15:55 -0000 1.238
--- src/backend/storage/buffer/bufmgr.c 26 Sep 2008 19:16:27 -0000
***************
*** 71,76 ****
--- 71,78 ----
/* local state for LockBufferForCleanup */
static volatile BufferDesc *PinCountWaitBuf = NULL;

+ /* local state for bulk inserts */
+ static Buffer BulkInsertBuffer = InvalidBuffer;

static Buffer ReadBuffer_relcache(Relation reln, ForkNumber forkNum,
BlockNumber blockNum, bool zeroPage, BufferAccessStrategy strategy);
***************
*** 2193,2198 ****
--- 2195,2230 ----
}

/*
+ * BulkInsertBuffer manipulation
+ */
+ Buffer
+ GetBulkInsertBuffer(void)
+ {
+ return BulkInsertBuffer;
+ }
+
+ void
+ SetBulkInsertBuffer(Buffer buffer)
+ {
+ BulkInsertBuffer = buffer;
+ }
+
+ void
+ ReleaseBulkInsertBufferIfAny(void)
+ {
+ if (BufferIsValid(BulkInsertBuffer))
+ ReleaseBuffer(BulkInsertBuffer);
+
+ BulkInsertBuffer = InvalidBuffer;
+ }
+
+ void
+ AtEOXact_BulkInsert(void)
+ {
+ BulkInsertBuffer = InvalidBuffer;
+ }
+
+ /*
* IncrBufferRefCount
* Increment the pin count on a buffer that we have *already* pinned
* at least once.
Index: src/include/access/heapam.h
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/include/access/heapam.h,v
retrieving revision 1.138
diff -c -r1.138 heapam.h
*** src/include/access/heapam.h 11 Aug 2008 11:05:11 -0000 1.138
--- src/include/access/heapam.h 26 Sep 2008 19:16:27 -0000
***************
*** 84,91 ****
ItemPointer tid);
extern void setLastTid(const ItemPointer tid);

extern Oid heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm);
extern HTSU_Result heap_delete(Relation relation, ItemPointer tid,
ItemPointer ctid, TransactionId *update_xmax,
CommandId cid, Snapshot crosscheck, bool wait);
--- 84,93 ----
ItemPointer tid);
extern void setLastTid(const ItemPointer tid);

+ void heap_begin_bulk_insert(void);
+ void heap_end_bulk_insert(void);
extern Oid heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm, bool bulk_insert);
extern HTSU_Result heap_delete(Relation relation, ItemPointer tid,
ItemPointer ctid, TransactionId *update_xmax,
CommandId cid, Snapshot crosscheck, bool wait);
Index: src/include/access/hio.h
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/include/access/hio.h,v
retrieving revision 1.36
diff -c -r1.36 hio.h
*** src/include/access/hio.h 19 Jun 2008 00:46:06 -0000 1.36
--- src/include/access/hio.h 26 Sep 2008 19:16:27 -0000
***************
*** 21,26 ****
extern void RelationPutHeapTuple(Relation relation, Buffer buffer,
HeapTuple tuple);
extern Buffer RelationGetBufferForTuple(Relation relation, Size len,
! Buffer otherBuffer, bool use_fsm);

#endif /* HIO_H */
--- 21,26 ----
extern void RelationPutHeapTuple(Relation relation, Buffer buffer,
HeapTuple tuple);
extern Buffer RelationGetBufferForTuple(Relation relation, Size len,
! Buffer otherBuffer, bool use_fsm, bool bulk_insert);

#endif /* HIO_H */
Index: src/include/storage/bufmgr.h
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/include/storage/bufmgr.h,v
retrieving revision 1.115
diff -c -r1.115 bufmgr.h
*** src/include/storage/bufmgr.h 11 Aug 2008 11:05:11 -0000 1.115
--- src/include/storage/bufmgr.h 26 Sep 2008 19:16:27 -0000
***************
*** 197,202 ****
--- 197,207 ----

extern void AtProcExit_LocalBuffers(void);

+ extern Buffer GetBulkInsertBuffer(void);
+ extern void SetBulkInsertBuffer(Buffer buffer);
+ extern void ReleaseBulkInsertBufferIfAny(void);
+ extern void AtEOXact_BulkInsert(void);
+
/* in freelist.c */
extern BufferAccessStrategy GetAccessStrategy(BufferAccessStrategyType btype);
extern void FreeAccessStrategy(BufferAccessStrategy strategy);
On Fri, 2008-09-26 at 20:07 +0200, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > Simon Riggs <simon@2ndQuadrant.com> writes:
> >> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> >>> samples % symbol name
> >>> 55526 16.5614 LWLockAcquire
> >>> 29721 8.8647 DoCopy
> >>> 26581 7.9281 CopyReadLine
> >>> 25105 7.4879 LWLockRelease
> >>> 15743 4.6956 PinBuffer
> >>> 14725 4.3919 heap_formtuple
> >
> >> Probably loading a table with a generated PK or loading data in
> >> ascending sequence, so its contending heavily for the rightmost edge of
> >> the index.
> >
> > No, given that DoCopy and CopyReadLine are right up there, I think we're
> > still looking at the COPY phase, not index building.
> >
> > The profile will probably change completely once index building
> > starts...
>
> yeah this profile is only showing the COPY phase ...

Try using this Postgres core patch. It's a updated version of my
fast_copy.v4.patch from Patches: Bulk Insert tuning 20 Mar 2008

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Re: [pgsql-es-ayuda] Consulta plpgsql

estas poniendo asi:
EXECUTE 'SELECT count(SF.nro_base) as cantidadFamilia, SF.nro_base
FROM SocioFamiliar as SF
GROUP BY SF.nro_base'
INTO familiaresTemp;

poner asi

EXECUTE 'SELECT count(SF.nro_base) as cantidadFamilia, SF.nro_base
INTO TEMPORARY familiaresTemp
FROM SocioFamiliar as SF
GROUP BY SF.nro_base' ;

-
/*
## Emanuel CALVO FRANCO. ##
~-~- 3m4nuek ~-~-
*/
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

[COMMITTERS] libpqtypes - libpqtypes: removed reference to old Object Hooks libpq

Log Message:
-----------
removed reference to old Object Hooks libpq patch from README

Modified Files:
--------------
libpqtypes:
README (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/README.diff?r1=1.5&r2=1.6)
configure.ac (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/configure.ac.diff?r1=1.4&r2=1.5)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgsql-advocacy] Going to XLDB

Folks,

I'm attending Stanford's XLDB[1] (eXtremely Large Databases) conference as
the PostgreSQL representative for the first time. This will be cool.

Send me any huge PostgreSQL data warehouse war stories which you have.

[1]http://www-conf.slac.stanford.edu/xldb08/

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [SQL] Finding sequential records

oops I noticed I forgot the having clause:

> SELECT id
> FROM Dummy
> GROUP BY name, fkey_id
Having count(*) > 1;


> SELECT A.*
> FROM ( SELECT ID
> FROM Dummy
> GROUP BY name, fkey_id
HAVING count(*) > 1 ) AS A
> INNER JOIN Dummy AS D
> ON A.id - 1 = D.id
> OR A.id + 1 = D.id;


--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

[COMMITTERS] libpqtypes - libpqtypes: updated man page to clarify docs -

Log Message:
-----------
updated man page to clarify docs - PQtypesRegister.3

Modified Files:
--------------
libpqtypes/docs/man3:
PQtypesRegister.3 (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/docs/man3/PQtypesRegister.3.diff?r1=1.1&r2=1.2)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] libpqtypes - libpqtypes: updated make file so its aware of new man page

Log Message:
-----------
updated make file so its aware of new man page PQtypesRegister.3

Modified Files:
--------------
libpqtypes:
Makefile.am (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/Makefile.am.diff?r1=1.7&r2=1.8)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] libpqtypes - libpqtypes: removed PQtypesObjectHooks.3 and added

Log Message:
-----------
removed PQtypesObjectHooks.3 and added PQtypesRegister to reflect libpq new event system

Added Files:
-----------
libpqtypes/docs/man3:
PQtypesRegister.3 (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/docs/man3/PQtypesRegister.3?rev=1.1&content-type=text/x-cvsweb-markup)

Removed Files:
-------------
libpqtypes/docs/man3:
PQtypesObjectHooks.3
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/docs/man3/PQtypesObjectHooks.3)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [SQL] Problem with pg_connect() in PHP

--- On Fri, 9/26/08, Edward W. Rouse <erouse@comsquared.com> wrote:

> From: Edward W. Rouse <erouse@comsquared.com>
> Subject: Re: [SQL] Problem with pg_connect() in PHP
> To: "'pgsql-sql'" <pgsql-sql@postgresql.org>
> Date: Friday, September 26, 2008, 5:23 PM
> Can I assume the missing '."' From the end of
> PG_PASSWORD is a cut and paste error?
>
>
>
> Edward W. Rouse
>
>
>
> From: pgsql-sql-owner@postgresql.org
> [mailto:pgsql-sql-owner@postgresql.org] On Behalf Of James
> Kitambara
> Sent: Friday, September 26, 2008 1:22 AM
> To: pgsql-sql
> Cc: Kenichiro Arakaki; Ken Arakaki
> Subject: [SQL] Problem with pg_connect() in PHP
>
>
>
>
> Dear Members of
>
> I have installed the Apache 2.0.61, PHP 5.2.4 and
> PostgreSQL 8.1 on my local computer.
>
> All three software were successfully tested. I changed
> ";extension=php_pgsql.dll" to
>
> "extension=php_pgsql.dll" in the php.ini file in
> order to enable PostgreSQL in PHP.
>
> The problem comes when I try to connect to the PostgreSQL
> Database using php function pg_connect
>
> $dbconn = pg_connect("host=".PG_HOST_NAME."
> port=".PG_PORT_NUM."
> dbname=".PG_DB_NAME." user=".PG_USER."
> password=".PG_PASSWORD);
>
> All the arguments in the function pg_connect() are defined.
>
> Unfortunately I am getting the Fatal error: "Call to
> undefined function pg_connect() in
> C:\Web\html\Staff_Management\example1.php on
> line 23"
>
> C:\Web\html is my document root.
>
> What could be the possible mistake?
>
> Anyone to assist me!
>
> Best regards,
>
> James Kitambara

first create a file that contains this

<? phpinfo(); ?>

save this with php extension, run this file from the browser and seek for the directory extension, then look if the file php_pgsql.dll is there

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

[GENERAL] Is there any way to reliably influence WHERE predicate evaluation ordering?

I've been working with some views that UNION ALL two tables and are
also updatable. On field in the view ('committed') simply indicates
what table a row came from. I don't want people to try and update
that field and think it'll take effect, so I have an assert function:

CREATE OR REPLACE RULE test_v__update AS ON UPDATE TO test_v DO INSTEAD
UPDATE test_committed set i=NEW.i
WHERE ( s=OLD.s )
AND assert( NOT NEW.committed IS DISTINCT FROM
OLD.committed, 'Changing committed is not allowed' )
;

All fine and good, but the assert would fire on this case:

update test_v set committed = true,i=i+1 WHERE s=1;

Where s=1 is absolutely a row in the 'committed' table. I finally
added some debugging and found the problem:

NOTICE: OLD.committed = TRUE
NOTICE: NOT DISTINCT =TRUE
NOTICE: NEW.committed = TRUE
NOTICE: NOT DISTINCT with s =TRUE
NOTICE: OLD.committed = FALSE
NOTICE: NOT DISTINCT =FALSE

AHA! The debug functions (and therefor the assert) was being
evaluated for each row in either table, even if they're marked as
IMMUTABLE.

This poses a problem in 2 ways: first, it means that every assert has
to include s = OLD.s AND ..., complicating code. But perhaps even
worse, it looks like the functions will force evaluation to happen
for every row in each table. That's not going to cut it on a multi-
million row table...

Changing the rule so that the functions were actually executed as
part of the SET seems to have solved the issue, but it's *really* ugly:

CREATE OR REPLACE RULE test_v__update AS ON UPDATE TO test_v DO INSTEAD
UPDATE test_committed set i=NEW.i
, s = CASE WHEN assert( NOT NEW.committed IS DISTINCT
FROM OLD.committed, 'Changing committed is not allowed' ) THEN s ELSE
NULL END
WHERE s=OLD.s
;

I suspect I could do something like

CREATE OR REPLACE RULE ...
UPDATE test_committed SET i = NEW.i
WHERE s IN ( SELECT s FROM ( SELECT s, assert(...) FROM
test_committed WHERE s = OLD.s ) a )
;

instead, but I haven't found a way to do that without making matters
worse...

Does anyone have any ideas on a clean and reliable way to do this?
What I think would be ideal is if there was some way to force
evaluation order in the WHERE clause of the update, but I don't think
that's possible.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [HACKERS] About the parameter of API: PQprepared

On Fri, Sep 26, 2008 at 2:45 AM, iihero <iihero@gmail.com> wrote:
> In libpq, the definition is like:
> PGresult *
> PQprepare(PGconn *conn,
> const char *stmtName, const char *query,
> int nParams, const Oid *paramTypes)
>
> Could we remove the parameter "nParams"?
> e.g. "insert into foo(id, name, address) values ($1, $2, $3)"
> PostgreSQL possibly can parse the prepared sql statement to get the real
> paramters count.
>
> Or, is there another alternate way?

if you are looking for easier way to do things like prepared
statements, etc. over libpq, you may want to look at libpqtypes (it's
a external library that will require a patched libpq for versions
<8.4):

http://libpqtypes.esilo.com/

merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgus-general] Nominations for PgUS Board: Weekly update (for the week ending 09/26/2008)

Greetings, y'all! This is the weekly update on the state of
nominations for the PgUS board.

Currently, we have six nominations for the four open seats; the
following people have accepted their nominations:

# # # # # # # #

Richard Broersma, Jr.: richard.broersma@gmail.com

Andrew Dunstan: andrew@dunslane.net

Ned Lilly: ned@xtuple.com

Greg Subino Mullane: greg@endpoint.com

Gavin Roy: gmr@myyearbook.com

Robert Treat: xzilla@users.sourceforge.net

# # # # # # # #

Remember, there's still time to get your nominations in; please
submit nominations (of yourself or of others) to:

secretary@postgresql.us

(Please include a contact email address.) I will contact the nominees
(to see if they accept the nomination) and report weekly to
pgus-general the list of current nominees.

Nominations will close on September 30th.

Also, remember: You can now use the following URL to become a member
of the United States PostgreSQL Association (PgUS):

https://www.postgresql.us/join

Note the special combo rate for PgUS professional membership and
PostgreSQL Conference West (October 10-12) registration; you can view
a partial list of the West talks here:

http://www.postgresqlconference.org/west08/talks/

Thanks, everyone!

---Michael Brewer
Secretary, PgUS
mbrewer@gmail.com
secretary@postgresql.us

--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general

Re: [SQL] Problem with pg_connect() in PHP


On Sep 26, 2008, at 12:23 PM, Edward W. Rouse wrote:

Can I assume the missing '."' From the end of PG_PASSWORD is a cut and paste error?
 
Edward W. Rouse
 
From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org] On Behalf Of James Kitambara
Sent: Friday, September 26, 2008 1:22 AM
To: pgsql-sql
Cc: Kenichiro Arakaki; Ken Arakaki
Subject: [SQL] Problem with pg_connect() in PHP
 
Dear Members of
I have installed the Apache 2.0.61,  PHP 5.2.4 and PostgreSQL 8.1 on my local computer.
All three software were successfully tested. I changed ";extension=php_pgsql.dll"  to
"extension=php_pgsql.dll"    in the php.ini file in order to enable PostgreSQL in PHP.
The problem comes when I try to connect to the PostgreSQL Database using php function pg_connect
$dbconn = pg_connect("host=".PG_HOST_NAME." port=".PG_PORT_NUM."  dbname=".PG_DB_NAME." user=".PG_USER." password=".PG_PASSWORD);
All the arguments in the function pg_connect() are defined.
Unfortunately I am getting the Fatal error: "Call to undefined function pg_connect() in C:\Web\html\Staff_Management\example1.php on line 23"
C:\Web\html is my document root.
What could be the possible mistake?
Anyone to assist me!
Best regards,
James Kitambara
 

Did you re-start apache after you made the changes to the php.ini file?

Ries








Re: [HACKERS] lock contention on parallel COPY ?

On Fri, 2008-09-26 at 14:00 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> >> samples % symbol name
> >> 55526 16.5614 LWLockAcquire
> >> 29721 8.8647 DoCopy
> >> 26581 7.9281 CopyReadLine
> >> 25105 7.4879 LWLockRelease
> >> 15743 4.6956 PinBuffer
> >> 14725 4.3919 heap_formtuple
>
> > Probably loading a table with a generated PK or loading data in
> > ascending sequence, so its contending heavily for the rightmost edge of
> > the index.
>
> No, given that DoCopy and CopyReadLine are right up there, I think we're
> still looking at the COPY phase, not index building.
>
> The profile will probably change completely once index building
> starts...

Sorry, was assuming we were loading with indexes on, which is wrong.

Agree the profile looks odd.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Need Some Explanation of an EXPLAIN

On Fri, Sep 26, 2008 at 12:13 PM, Bill Thoen <bthoen@gisnet.com> wrote:
> I'm trying to update a field in a table that has about 5 millin records with
> a table that has about 3.5 million records. I've created indexes for th a
> joined columns, but PostgreSQL 8.1 doesn't seem to want to use them. This
> makes for a very slow update.

8.3 is a bit smarter on some of these types of queries, updating to
that may (or may not) help in this situation.

> 1.) Why won't it use the indexes?

The pgsql planner chooses whether to use indexes versus sequential
scans based on whether one or the other is "cheaper" to use.

> 2.) How can I make this update faster?

Get a faster server?

> fsa=# EXPLAIN UPDATE growers
> SET grower_id = id2.grower_id
> FROM id2 WHERE growers.fsa_id = id2.fsa_id;
> QUERY PLAN
> --------------------------------------------------------------------------
> Hash Join (cost=70375.50..1603795.30 rows=6802720 width=355)
> Hash Cond: ("outer".fsa_id = "inner".fsa_id)
> -> Seq Scan on growers (cost=0.00..672373.20 rows=6802720 width=351)
> -> Hash (cost=46249.20..46249.20 rows=1966920 width=44)
> -> Seq Scan on id2 (cost=0.00..46249.20 rows=1966920 width=44)

1: Post explain analyze (if you can wait long enough for the update to finish.
2: Is the table bloated from multiple updates? Have you been
vacuuming between each update you've tested? Do you have autovacuum
enabled and is it aggresive enough to keep up?
3: If you want to force pgsql to use an index for testing purposes,
try running this before your update query:

set enable_indexscan=off;

and see if it's faster or slower.

Pgsql indexes don't have visibility, and this contributes to the
higher cost of index scans on pgsql than some other dbs. However,
sequential scans make sense if you're updating the whole table in
almost any database.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Need Some Explanation of an EXPLAIN

I'm trying to update a field in a table that has about 5 millin records
with a table that has about 3.5 million records. I've created indexes
for th a joined columns, but PostgreSQL 8.1 doesn't seem to want to use
them. This makes for a very slow update.

Below are descriptions of the two tables followed by the query plan that
my PostgreSQL wants to use. So I have two questions:

1.) Why won't it use the indexes?
2.) How can I make this update faster?

TIA,
Bill Thoen


Table "public.id2"
Column | Type | Modifiers
-----------+--------------+-----------
grower_id | integer |
fmid | character(7) |
fsa_id | character(9) |
Indexes:
"id2_fsa_is_key" UNIQUE, btree (fsa_id)

Table "public.growers"
Column | Type | Modifiers
--------------+-----------------------+-----------
grower_id | integer |
fsa_id | character(9) |
co_name | character varying(45) |
. . .
Indexes:
"grower_fsa_id_key" btree (fsa_id)

fsa=# EXPLAIN UPDATE growers
SET grower_id = id2.grower_id
FROM id2 WHERE growers.fsa_id = id2.fsa_id;

QUERY PLAN
--------------------------------------------------------------------------
Hash Join (cost=70375.50..1603795.30 rows=6802720 width=355)
Hash Cond: ("outer".fsa_id = "inner".fsa_id)
-> Seq Scan on growers (cost=0.00..672373.20 rows=6802720 width=351)
-> Hash (cost=46249.20..46249.20 rows=1966920 width=44)
-> Seq Scan on id2 (cost=0.00..46249.20 rows=1966920 width=44)
(5 rows)


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [SQL] Finding sequential records

Can this be what you need?

Best,
Oliveiros

SELECT id
FROM dummy a
NATURAL JOIN
(
SELECT fkey_id,name
FROM dummy
GROUP BY fkey_id,name
HAVING COUNT(*) > 1
AND SUM(id) = (MAX(id) + MIN(id)) * (MAX(id) - MIN(id) + 1) / 2
) b
ORDER BY id;


----- Original Message -----
From: "Steve Midgley" <science@misuse.org>
To: <pgsql-sql@postgresql.org>
Sent: Friday, September 26, 2008 6:39 PM
Subject: [SQL] Finding sequential records


> Hi,
>
> I've been kicking this around today and I can't think of a way to solve
> my problem in "pure SQL" (i.e. I can only do it with a
> looping/cursor-type solution and some variables).
>
> Given a table with this DDL/data script:
>
> drop table if exists dummy;
> create table dummy (
> id integer primary key,
> name varchar(255),
> fkey_id integer
> )
> ;
> insert into dummy (id, name, fkey_id) values (502163,'3Br/3Ba Pool
> Villa in Westin St. John, USVI- Summer 2008',500100);
> insert into dummy (id, name, fkey_id) values (502164,'3Br/3Ba Pool
> Villa in Westin St. John, USVI- Summer 2008',500100);
> insert into dummy (id, name, fkey_id) values (502169,'Lazy Bear
> Lodge',105);
> -- not sequential id to previous
> insert into dummy (id, name, fkey_id) values (502199,'Lazy Bear
> Lodge',105);
> insert into dummy (id, name, fkey_id) values (502170,'3 Bed, 1 Bath
> Cottage Less Than a Mile from West Dennis Beach',500089);
> insert into dummy (id, name, fkey_id) values (502171,'3 Bed, 1 Bath
> Cottage Less Than a Mile from West Dennis Beach',500089);
> -- not sequential id nor duplicate fkey_id to previous
> insert into dummy (id, name, fkey_id) values (502175,'3 Bed, 1 Bath
> Cottage Less Than a Mile from West Dennis Beach',500102);
> insert into dummy (id, name, fkey_id) values (502213,'Sea
> Watch',500128);
> -- not duplicate fkey_id to previous
> insert into dummy (id, name, fkey_id) values (502214,'Sea
> Watch',500130);
>
> Find all instances where
> * name is duplicated
> * fkey_id is the same (for the any set of duplicated name fields)
> * id is sequential (for any set of duplicated name fields)
>
> The system should return
>
> 502163
> 502164
> 502170
> 502171
>
> Here's as far as I got:
>
> select id
> from dummy
> where
> name in (
> select name from dummy
> group by name
> having count(name)>1
> )
> order by id
>
> I can't figure out how to test for duplicate fkey_id when name is the
> same, nor to test for sequential id's when name is the same.
>
> Having a method for either would be great, and both would be a bonus!
>
> It seems like there's a clever way to do this without cursors but I
> can't figure it out!
>
> Thanks for any help!
>
> Steve
>
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [HACKERS] Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)

"Alex Hunsaker" <badalex@gmail.com> writes:
> However that still leaves the original complaint around (at least IMHO):

> select to_timestamp('AN', 'AM');
> ERROR: invalid AM/PM string

> select to_timestamp('11:47 PM 27 Sep a2008', 'HH:MI PM DD Mon YYYY');
> ERROR: invalid value for "YYYY" in source string

Yeah, it would be a lot better if it said

ERROR: invalid value for "YYYY": "a2008"

The DETAIL is good too, but it's no substitute for showing the exact
substring that the code is unhappy about.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Consulta plpgsql

Hola lista!

Espero que anden bien. Estoy en un brete, tengo q entregar un Trabajo Practico y estoy tratando de hacer andar un Stored Procedure que hizo una compañera en SQLServer.
Basicamente, la idea del algoritmo es ir haciendo ciertas consultas, almacenarlas en tablas temporales y al final hacer un join con dos de ellas y una tabla comun y mostrar el resultado de dicho join.
Cuando empecé a pasarlo, me encontré con que no se puede hacer select into temp table dentro del Stored procedure, diganme si me equivoco.
Luego declare todas mis tempTables como variables record.
Actualmente, el error que me tira, es que no tengo definido el formato de la tabla, leí por ahí que puedo definirlo como el formato de otra tabla al definir la variable, pero no tengo ninguna tabla con la misma estructura.
Como sería la manera correcto de resolverlo?
Les adjunto al final el codigo.
Muchas gracias

Moski

CREATE OR REPLACE FUNCTION deudasSocios ()  RETURNS setof record AS $$
    DECLARE
    SocDeudaActualTemp FacturaCuota%rowtype;
    FacturaCuotaTemp record;
    SocDeudaAnteriorTemp record;
    deudaActualTemp record;
    deudaAnteriorTemp record;
    SocioDeudaTemp record;
    familiaresTemp record;

    BEGIN
   
    /*devuelve la mayor fecha de vencimiento de cada socio del a�o actual*/
    EXECUTE 'SELECT FC.Nro_Base, max(FC.fecha_vencimiento) as fecha_vencimiento
    FROM FacturaCuota as FC
    GROUP BY FC.Nro_Base'
    INTO SocDeudaActualTemp;

    /*devuelve todas las facturas del a�o anterior*/
    EXECUTE 'SELECT *
    FROM FacturaCuota as FC
    WHERE extract(year from FC.fecha_vencimiento) = extract(year from current_date) - 1'
    INTO FacturaCuotaTemp;

    /*devuelve la mayor fecha de vencimiento de cada socio del a�o anterior*/
    EXECUTE 'SELECT FC.Nro_Base, max(FC.fecha_vencimiento) as fecha_vencimiento
    FROM FacturaCuotaTemp as FC
    GROUP BY FC.Nro_Base'
    INTO SocDeudaAnteriorTemp;

    /*devuelve la deuda acumulada hasta el momento*/
    EXECUTE 'SELECT FC.Nro_Base, FC.deuda as deuda
    FROM SocDeudaActualTemp, FacturaCuota as FC
    WHERE FC.Nro_Base = SocDeudaActualTemp.Nro_Base and
    FC.fecha_vencimiento = SocDeudaActualTemp.fecha_vencimiento '
    INTO deudaActualTemp;

    /*devuelve la deuda acumulada hasta el a�o anterior*/
    EXECUTE 'SELECT FC.Nro_Base, FC.deuda as deuda
    FROM SocDeudaAnteriorTemp, FacturaCuota as FC
    WHERE FC.Nro_Base = SocDeudaAnteriorTemp.Nro_Base and
    SocDeudaAnteriorTemp.fecha_vencimiento = FC.fecha_vencimiento'
    INTO deudaAnteriorTemp;

    /*devuelve la deuda del ultimo a�o*/
    EXECUTE 'SELECT deudaActualTemp.nro_base, (deudaActualTemp.deuda - deudaAnteriorTemp.deuda) as deuda
    FROM deudaActualTemp, deudaAnteriorTemp
    WHERE deudaAnteriorTemp.Nro_Base = deudaActualTemp.Nro_Base and
    (deudaActualTemp.deuda - deudaAnteriorTemp.deuda) > 0'
    INTO SocioDeudaTemp ;

    /*devuelve la cantidad de socios familiares que tiene cada socio titular*/
    EXECUTE 'SELECT count(SF.nro_base) as cantidadFamilia, SF.nro_base
    FROM SocioFamiliar as SF
    GROUP BY SF.nro_base'
    INTO familiaresTemp;


    /*devuelve los datos del socio titular de grupos familiares que adeuden cuotas sociales del
    a�o en curso, junto con el importe total adeudado, y la cantidad de integrantes del
    grupo.*/
    RETURN QUERY SELECT  SocioDeudaTemp.deuda, familiaresTemp.cantidadFamilia, ST.*
        FROM quote_ident(SocioDeudaTemp), quote_ident(familiaresTemp), SocioTitular as ST
        WHERE SocioDeudaTemp.nro_base = familiaresTemp.nro_base and
        ST.nro_base = SocioDeudaTemp.nro_base;

   
    END;
$$ LANGUAGE 'plpgsql';


Re: [HACKERS] lock contention on parallel COPY ?

Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>> samples % symbol name
>>> 55526 16.5614 LWLockAcquire
>>> 29721 8.8647 DoCopy
>>> 26581 7.9281 CopyReadLine
>>> 25105 7.4879 LWLockRelease
>>> 15743 4.6956 PinBuffer
>>> 14725 4.3919 heap_formtuple
>
>> Probably loading a table with a generated PK or loading data in
>> ascending sequence, so its contending heavily for the rightmost edge of
>> the index.
>
> No, given that DoCopy and CopyReadLine are right up there, I think we're
> still looking at the COPY phase, not index building.
>
> The profile will probably change completely once index building
> starts...

yeah this profile is only showing the COPY phase ...

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)

On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd <direvus@gmail.com> wrote:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names. This would make it easy to accept any flavour of marker,
> and the error messages thrown for bogus input would then be the same
> as those for bogus day and month names.

Yeah if we seq_search then it should be a pretty easy conversion. so +1

However that still leaves the original complaint around (at least IMHO):

select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string

select to_timestamp('11:47 PM 27 Sep a2008', 'HH:MI PM DD Mon YYYY');
ERROR: invalid value for "YYYY" in source string


Now arguably most to_timestamp calls are going to be short so i can
easily look for the YYYY in my string and see what I did wrong (and
DETAIL: provides Value must be an integer in the second case)... So
really maybe thats good enough I dunno... Personally I find the output
of my dumb patch to be better than both above:

select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string for 'AN'

And we could improve that by only showing node->key->len chars. And
make that work for both AM/PM and the others YYYY etc

Then again maybe its not worth it?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [SQL] Finding sequential records

On Fri, Sep 26, 2008 at 10:39 AM, Steve Midgley <science@misuse.org> wrote:
> drop table if exists dummy;
> create table dummy (
> id integer primary key,
> name varchar(255),
> fkey_id integer
> )
> ;

> The system should return
>
> 502163
> 502164
> 502170
> 502171


--first get all of the duplicated ids

SELECT id
FROM Dummy
GROUP BY name, fkey_id


--Next from this list find check to see if there are any sibling
immediate above or below it.

SELECT A.*
FROM ( SELECT ID
FROM Dummy
GROUP BY name, fkey_id ) AS A
INNER JOIN Dummy AS D
ON A.id - 1 = D.id
OR A.id + 1 = D.id;

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [HACKERS] lock contention on parallel COPY ?

Simon Riggs <simon@2ndQuadrant.com> writes:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> samples % symbol name
>> 55526 16.5614 LWLockAcquire
>> 29721 8.8647 DoCopy
>> 26581 7.9281 CopyReadLine
>> 25105 7.4879 LWLockRelease
>> 15743 4.6956 PinBuffer
>> 14725 4.3919 heap_formtuple

> Probably loading a table with a generated PK or loading data in
> ascending sequence, so its contending heavily for the rightmost edge of
> the index.

No, given that DoCopy and CopyReadLine are right up there, I think we're
still looking at the COPY phase, not index building.

The profile will probably change completely once index building
starts...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [Probablemente Spam] Re: [pgsql-es-ayuda] PostgreSQL Spanish Documentation Project and Developmented create od Event next Year for Latin America for Country Regional

--- El vie 26-sep-08, Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu> escribió:

> De: Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu>
> Asunto: Re: [Probablemente Spam] Re: [pgsql-es-ayuda] PostgreSQL Spanish Documentation Project and Developmented create od Event next Year for Latin America for Country Regional
> A: "Ernesto Lozano" <elozanohia@gmail.com>
> Cc: "postgres Emanuel CALVO FRANCO" <postgres.arg@gmail.com>, pgsql-es-ayuda@postgresql.org, lobus1@cantv.net
> Fecha: viernes, 26 septiembre, 2008, 2:50 pm
> Ernesto:
>
> Por nuestra parte estoy esperando el acceso los fuentes del
> Webtrasletion ... y demás para comenzar con los trabajos
> de rescate del
> proyecto.
>
> En Cuba estamos listo para crear las comisiones que
> necesitemos para
> seguir adelante con los trabajos.
>
> Saludos,
> Gilberto.
>
Gilberto capaz que ya estan en eso pero por las dudas te sugiero conectarte con Reyneer de UCI, asi no duplican esfuerzos, ya que
no se puede correr el riesgo de duplcar trabajo, cuando hay tanto
por hacer.

Particularmente veo muy poco en lo que pueda colaborar lo cual me apena
pero a las ordenes si puedo colaborar en algo.

Pero si puedo intentar buscar que la gente que usamos postgresql en mi pais nos juntemos a tomar unos mates y ver que podemos hacer para sumarnos
a la causa.

Atte. Gabriel Colina
Uruguay


> El vie, 26-09-2008 a las 11:27 -0430, Ernesto Lozano
> escribió:
> > Estimados Amigos de la Comunidad
> >
> > Placer saludarlos nuestra organizacion esta presta
> para apoyar la
> > traduccion estoy copiando a nuestro responsable que
> hemos designado a
> > Alfonso Lopez para este proyecto a integrarse con
> ustedes para llevar
> > a cabo este projecto
> >
> > Espero que podamos lograr los objetivos propuestos y
> sigue en Pie la
> > propuesta de organizar Talleres Regionales o
> Tutoriales para Postgres
> > en nuestra America Latina vamos a crear el comite de
> la Region Global
> > para crear comiteb en cada Pais para lograr el impulso
> esperado
> >
> > Mis Saludos y Respetos
> >
> > Ernesto Lozano
> > Director General
> > HIA TECHNOLOGY DE VENEZUELA
> > Telefono Master 00582418672023
> > Email elozano@hiatechnology.com.ve
> >
> > 2008/9/26, postgres Emanuel CALVO FRANCO
> <postgres.arg@gmail.com>:
> > > En que quedo el tema de la traduccion??
> > > --
> > > TIP 3: Si encontraste la respuesta a tu problema,
> publícala, otros te lo
> > > agradecerán
> > >
> > --
> > TIP 6: ¿Has buscado en los archivos de nuestra
> lista de correo?
> >
> http://archives.postgresql.org/pgsql-es-ayuda
> >
>
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien
> responda no podrá leerlo


____________________________________________________________________________________
Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda