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
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
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
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
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
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
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
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
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 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.
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
11 matches
Mail list logo
