Dear Developers,
Thanks for your answers. I didn't know about
generate_series, but it looks to be exactly what
I was suggesting.
Regards,
Sorin Schwimmer
Do you Yahoo!?
Everyone is raving about the all-new Ya
Sorin Schwimmer <[EMAIL PROTECTED]> writes:
> My suggestion is to allow INSERT to do it REPEAT x.
You can do that today.
INSERT INTO foo SELECT const1,const2,... FROM generate_series(1,1000);
regards, tom lane
---(end of broadcast)
On Wed, 24 Jan 2007, Sorin Schwimmer wrote:
> Dear Developers,
>
> I would like to suggest the inclusion of an extension
> in PostgreSQL. There are instances, I found, when one
> needs to INSERT several times the same record in a
> table. The front-end application can do it easy in a
> loop of a s
On Wed, 2007-01-24 at 08:26 -0800, Sorin Schwimmer wrote:
> The front-end application can do it easy in a
> loop of a sort, but on remote servers (and that's the
> norm these days) it creates unnecessary network
> traffic.
You can avoid this easily via a stored procedure.
> My suggestion is to al
Dear Developers,
I would like to suggest the inclusion of an extension
in PostgreSQL. There are instances, I found, when one
needs to INSERT several times the same record in a
table. The front-end application can do it easy in a
loop of a sort, but on remote servers (and that's the
norm these days
On Fri, 2006-05-19 at 12:35 -0700, Marc Munro wrote:
> On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> > This could all be solved in a cleaner, more bulletproof way if you
> > simply require such add-ins to be preloaded into the postmaster process
> > using the existing preload_libraries hook.
On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > My proposal makes it possible for properly configured add-ins to have a
> > guaranteed amount of shared memory available.
>
> This could all be solved in a cleaner, more bulletproof way if you
> simply
Marc Munro <[EMAIL PROTECTED]> writes:
> My proposal makes it possible for properly configured add-ins to have a
> guaranteed amount of shared memory available.
This could all be solved in a cleaner, more bulletproof way if you
simply require such add-ins to be preloaded into the postmaster proces
On Fri, 2006-05-19 at 10:05 -0700, Josh Berkus wrote:
> Marc,
>
> > The add-in would not "know" how much had been allocated to it, but could
> > be told through it's own config file. I envisage something like:
> >
> > in postgresql.conf
> >
> > # add_in_shmem = 0# Amount of shared mem to set
Marc,
> The add-in would not "know" how much had been allocated to it, but could
> be told through it's own config file. I envisage something like:
>
> in postgresql.conf
>
> # add_in_shmem = 0 # Amount of shared mem to set aside for add-ins
> # in KBytes
> add_in_shem =
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> On Thu, 2006-05-18 at 17:39 -0700, Marc Munro wrote:
>
> > For Postgres 8.2 I would like Veil to be a better citizen and use
> only
> > what shared memory has been reserved for postgres add-ins.
>
> How would Postgres ask the add-in ho
Marc Munro wrote:
Veil http://pgfoundry.org/projects/veil is currently not a very good
Postgres citizen. It steals what little shared memory it needs from
postgres' shared memory using ShmemAlloc().
For Postgres 8.2 I would like Veil to be a better citizen and use only
what shared memory has be
On Thu, 2006-05-18 at 17:39 -0700, Marc Munro wrote:
> For Postgres 8.2 I would like Veil to be a better citizen and use only
> what shared memory has been reserved for postgres add-ins.
How would Postgres ask the add-in how much memory it needs? How would
the add-in know how much has been reserv
Veil http://pgfoundry.org/projects/veil is currently not a very good
Postgres citizen. It steals what little shared memory it needs from
postgres' shared memory using ShmemAlloc().
For Postgres 8.2 I would like Veil to be a better citizen and use only
what shared memory has been reserved for post
14 matches
Mail list logo
