> From: matioli.math...@gmail.com
> Date: Thu, 10 Jan 2013 16:45:43 -0200
> Subject: Partition insert trigger using C language
> To: pgsql-performance@postgresql.org
> CC: charle...@outlook.com
>
> Hi All,
>
> Inspired by Charles' thread and the work of Em
On Thu, Jan 10, 2013 at 5:22 PM, Heikki Linnakangas wrote:
> On 10.01.2013 21:11, Matheus de Oliveira wrote:
>
>> On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangas> vmware.com
>>
>>> wrote:
>>>
>>
>> The right way to do this with SPI is to prepare each insert-statement on
>>> first invocation
On 10.01.2013 21:11, Matheus de Oliveira wrote:
On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangas
wrote:
The right way to do this with SPI is to prepare each insert-statement on
first invocation (SPI_prepare + SPI_keepplan), and reuse the plan after
that (SPI_execute_with_args).
If you cons
2013/1/10 Heikki Linnakangas :
> On 10.01.2013 20:45, Matheus de Oliveira wrote:
>>
>> Inspired by Charles' thread and the work of Emmanuel [1], I have made some
>> experiments trying to create a trigger to make partitioning using C
>> language.
>>
>> The first attempt was not good, I tried to use
On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangas wrote:
> On 10.01.2013 20:45, Matheus de Oliveira wrote:
>
>> Inspired by Charles' thread and the work of Emmanuel [1], I have made some
>> experiments trying to create a trigger to make partitioning using C
>> language.
>>
>> The first attempt
On 10.01.2013 20:45, Matheus de Oliveira wrote:
Inspired by Charles' thread and the work of Emmanuel [1], I have made some
experiments trying to create a trigger to make partitioning using C
language.
The first attempt was not good, I tried to use SPI [2] to create a query to
insert into the cor
On Thu, Jan 10, 2013 at 11:32 AM, Andrzej Zawadzki wrote:
> Hi!
>
> Small query run on 9.0 very fast:
>
> SELECT * from sygma_arrear sar where sar.arrear_import_id = (
> select sa.arrear_import_id from sygma_arrear sa, arrear_import ai
> where sa.arrear_flag_id = 2
> AND s
On Thu, Jan 10, 2013 at 5:32 AM, Andrzej Zawadzki wrote:
>
> Why that's happens? All configurations are identical. Only engine is
> different.
Could you post explain (analyze, buffers) instead of just explain?
Also, if you temporarily set enable_seqscan=off on 9.2, what plan do
you then get?
Che
My best regards for all...
Please. I need for an advice.
I'm having a trouble, that puting others queries in wait state, becouse
of ExclusiveLock granted by an Update that only update one row at each
time. This update occurs into a function and this function are
executed several times and c
My best regards for all...
Please. I need for an advice.
I'm having a trouble, that puting others queries in wait state, becouse
of ExclusiveLock granted by an Update that only update one row at each
time. This update occurs into a function and this function are
executed several times and c
On 01/10/2013 02:51 AM, Henri Philipps wrote:
http://research.cs.wisc.edu/adsl/Publications/meehean-thesis11.pdf
Wow, that was pretty interesting. It looks like for servers, the O(1)
scheduler is much better even with the assignment bug he identified, and
BFS responds better to varying load
Hi!
Small query run on 9.0 very fast:
SELECT * from sygma_arrear sar where sar.arrear_import_id = (
select sa.arrear_import_id from sygma_arrear sa, arrear_import ai
where sa.arrear_flag_id = 2
AND sa.arrear_import_id = ai.id
AND ai.import_type_id = 1
order
Hi,
we also hit this performance barrier a while ago, when migrating a
database on a big server (48 core Opteron, 512GB RAM) from Kernel
2.6.32 to 3.2 (both kernels from Debian packages). The system load was
getting very high, as you also observed (don't know the exact numbers
right now).
After s
13 matches
Mail list logo
