Hi Guys,
Sorry for the late reply.
Thanks to all of you for the help. Appreciate all your suggestions.
So far (with my pretty limited knowledge of PG) I could speed it up a little
bit (~20% or so comparing to the original installation) only by "tweaking" the
settings.
I think it is relatively
On 26 Feb 2012, at 23:54, Tim Uckun wrote:
> The main reason I am not using COPY right now is because postgres will
> not allow unprivileged users to issue the COPY from FILENAME. The
> only way I could get around this would be to shell out psql or
> something but I dont really want to do that.
I have a situation where I am pulling CSV data from various sources
and putting them into a database after they are cleaned up and such.
Currently I am doing bulk of the work outside the database using code
but I think the work would go much faster if I was to use import the
data into temp tables u
On Sun, Feb 26, 2012 at 1:11 PM, Stefan Keller wrote:
> So to me the bottom line is, that PG already has reduced overhead at
> least for issue #2 and perhaps for #4.
> Remain issues of in-memory optimization (#2) and replication (#3)
> together with High Availability to be investigated in PG.
Ye
Thanks to all who responded so far. I got some more insights from Mike
Stonebraker himself in the USENIX talk Scott pointed to before.
I'd like to revise the four points a little bit I enumerated in my
initial question and to sort out what PG already does or could do:
1. Buffering Pool
To get rid
Em 26 de fevereiro de 2012 12:45, Clodoaldo Neto <
clodoaldo.pinto.n...@gmail.com> escreveu:
> When I explain a query using a partitioned table the result is the
> expected. That is, only the corrected partition is scanned. But when the
> query is inside a plpgsql function it takes forever to comp
Dave Potts writes:
> I have written an external C function to be called by postgres called
> using the LANGUAGE 'C' IMMUNTABLE STRICT interface
> Most of the time when call it, I get the expected results. Some times I
> get random rubbish in the result set.
> If there any debug support in Postgre
On Sun, Feb 26, 2012 at 08:37:54AM -0600, Andy Colson wrote:
>> 3. WAL logging
>
> PG writes a transaction twice. Once to WAL and once to
> the DB. WAL is a simple and quick write, and is only ever
> used if your computer crashes and PG has to re-play
> transactions to get the db into a good/kn
On 02/25/2012 06:54 PM, Stefan Keller wrote:
Hi,
Recently Mike Stonebraker identified four areas where "old elephants"
lack performance [1]:
1. Buffering/paging
2. Locking/Multithreading
3. WAL logging
4. Latches (aka memory locks for concurrent access of btree structures
in buffer pool?).
He
Ok. I did a manual patch and it Postgres 9.1.1 compiled for me without using
the --disable-spinlocks option.
Thanks a lot for the patch. :)
By the way, could you please point me to the explanation on the significance of
spinlocks for Postgres?
Thanks and Regards
Jayashankar
-Original Messag
Hi
I have written an external C function to be called by postgres called
using the LANGUAGE 'C' IMMUNTABLE STRICT interface
Most of the time when call it, I get the expected results. Some times I
get random rubbish in the result set.
Postgres always gets the type of the arguments correct, ie it
11 matches
Mail list logo
