Hi
plpgsql has zero optimization for this kind of functions. It is best glue
for SQL statements and relative bad for high expensive numeric
calculations. It is very simple AST interpret only.
Try to use PLPerl, PLPython, PLLua instead for this purposes.
Pavel
2014-08-04 22:48 GMT+02:00 testman
On 05/08/14 08:48, testman1316 wrote:
We am trying to get an idea of the raw performance of Oracle vs PostgreSQL.
We have extensive oracle experience but are new to PostgreSQL. We are going
to run lots of queries with our data, etc. But first we wanted to see just
how they perform on basic kernel
We am trying to get an idea of the raw performance of Oracle vs PostgreSQL.
We have extensive oracle experience but are new to PostgreSQL. We are going
to run lots of queries with our data, etc. But first we wanted to see just
how they perform on basic kernel tasks, i.e. math and branching since SQ
On Mon, Aug 4, 2014 at 1:22 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> Hello,
>
> > I think irrespective of that we can trim t1.c & t1.d as we have
> > primary key (unique and non column) for t1.a, t1.b. Basically
> > even if we don't use the primary key index, we can stil
On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
> Fujii Masao writes:
>> The patch chooses the last settings for every parameters and ignores the
>> former settings. But I don't think that every parameters need to be processed
>> this way. That is, we can change the patch so that only PGC_POSTMA
On Sat, Aug 2, 2014 at 1:40 PM, Jeff Davis wrote:
> This is a prerequisite for memory-bounded HashAgg, which I intend to
> submit for the next CF.
FWIW, I think that's a good project. A large number of these TPC-H
queries used HashAggs when I checked, on a moderate sized sample TPC-H
database:
h
This remains open for 9.4. Your proposal to revert the feature in 9.4 and fix
it in 9.5 sounds reasonable.
On Thu, Jul 10, 2014 at 04:15:35PM +0100, Greg Stark wrote:
> On Mon, Jul 7, 2014 at 8:35 AM, Sergey Muraviov
> wrote:
> > So what's wrong with the patch?
> > And what should I change in it
On 08/04/2014 07:54 AM, Robert Haas wrote:
> 1. Most seriously, once the postmaster is gone, there's nobody to
> SIGQUIT remaining backends if somebody exits uncleanly. This means
> that a backend running without a postmaster could be running in a
> corrupt shared memory segment, which could lead
Tom Lane wrote:
> Jeff Janes writes:
> > After 87306184580c9c49717, if the postmaster dies without cleaning up (i.e.
> > power outage), running "pg_ctl start" just gives this message and then
> > exits:
>
> > pg_ctl: another server might be running
>
> > Under the old behavior, it would try to s
On Sun, Aug 3, 2014 at 5:48 PM, Emre Hasegeli wrote:
> > > 1. This patch introduces a new "polygon <-> point" operator. That seems
> > > useful on its own, with or without this patch.
> >
> > Yeah, but exact-knn cant come with no one implementation. But it would
> > better come in a separate patc
On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
wrote:
>I really like the proposal of working on a block level incremental
> backup feature and the idea of considering LSN. However, I'd suggest
> to see block level as a second step and a goal to keep in mind while
> working on the first ste
David Rowley wrote:
> The only notes I can think to leave for the commiter would be around the
> precedence order of the lock policy, especially around a query such as:
>
> SELECT * FROM (SELECT * FROM a FOR UPDATE SKIP LOCKED) a FOR UPDATE; --
> skip locked wins
>
> Of course the current behavi
I have applied the attached patch to remove a reference to
autovacuum_multixact_freeze_max_age.
autovacuum_multixact_freeze_max_age was added as a pg_ctl start
parameter in 9.3.X to prevent autovacuum from running. However, only
some 9.3.X releases have autovacuum_multixact_freeze_max_age as it w
Hi,
I’m missing the PG_RETURN_UINT16 macro in fmgr.h
Since we already have the PG_GETARG_UINT16 macro
I guess it makes sense to to have it.
here is the trivial patch for it.
add_pg_return_uint16_macro.patch
Description: Binary data
cheers
Manuel
--
Sent via pgsql-hackers mailing list (
On Tue, Jul 29, 2014 at 3:33 AM, Josh Berkus wrote:
> On 07/28/2014 11:03 AM, Fujii Masao wrote:
>> On Sat, Jul 26, 2014 at 1:07 PM, Amit Kapila wrote:
>>> On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
wrote:
> Okay. As mentioned
On Thu, Jul 31, 2014 at 9:51 PM, Tom Lane wrote:
> "Baker, Keith [OCDUS Non-J&J]" writes:
>> Since ensuring there are not orphaned back-end processes is vital, could we
>> add a check for getppid() == 1 ?
>
> No. Or yeah, we could, but that patch would add no security worth
> mentioning. For e
Fujii Masao writes:
> The patch chooses the last settings for every parameters and ignores the
> former settings. But I don't think that every parameters need to be processed
> this way. That is, we can change the patch so that only PGC_POSTMASTER
> parameters are processed that way. The invalid s
While working on the SSL refactoring patch, it struck me that we don't
have any regression tests for SSL support. A suite to test all the
different sslmodes etc. is essential before we can start implementing
alternatives to OpenSSL.
Now that we use TAP for testing client tools, I think we can
On 08/04/2014 09:48 PM, Albe Laurenz wrote:
> There are valid use cases (else the function probably wouldn't exist).
> I use it in oracle_fdw to gracefully close any open Oracle connections when
> the process exits.
True; it's sometimes better to do a clean exit.
It's relying on that always happe
Craig Ringer wrote:
> On 08/04/2014 06:31 PM, Seref Arikan wrote:
>> Thanks a lot Heikki and Albe. Exactly what I was asking for.
>> Heikki: the libraries are written in languages that have their own
>> runtime and their documentation insists that both init and dispose calls
>> are performed when u
Hi,
On Mon, Aug 4, 2014 at 11:58 AM, Heikki Linnakangas wrote:
> On 08/04/2014 01:31 PM, Seref Arikan wrote:
>
>> Thanks a lot Heikki and Albe. Exactly what I was asking for.
>> Heikki: the libraries are written in languages that have their own runtime
>> and their documentation insists that bo
On 08/04/2014 06:31 PM, Seref Arikan wrote:
> Thanks a lot Heikki and Albe. Exactly what I was asking for.
> Heikki: the libraries are written in languages that have their own
> runtime and their documentation insists that both init and dispose calls
> are performed when used from C. PG_init() and
Hi Hanada-san,
Thank you for the answer.
(2014/08/04 19:36), Shigeru Hanada wrote:
2014-07-25 16:30 GMT+09:00 Etsuro Fujita :
(2014/07/24 18:30), Shigeru Hanada wrote:
I'm not sure that I understand your question correctly, but the reason for
that is because foreign tables cannot have INSTEAD
(2014/07/30 17:22), Etsuro Fujita wrote:
(2014/07/29 0:58), Robert Haas wrote:
On Fri, Jul 25, 2014 at 3:39 AM, Albe Laurenz
wrote:
Shigeru Hanada wrote:
* Naming of new behavior
You named this optimization "Direct Update", but I'm not sure that
this is intuitive enough to express this behavi
On 08/04/2014 01:31 PM, Seref Arikan wrote:
Thanks a lot Heikki and Albe. Exactly what I was asking for.
Heikki: the libraries are written in languages that have their own runtime
and their documentation insists that both init and dispose calls are
performed when used from C. PG_init() and proc_e
Hi Fujita-san,
Here is a new review result from Eitoku-san.
2014-07-25 16:30 GMT+09:00 Etsuro Fujita :
> (2014/07/24 18:30), Shigeru Hanada wrote:
> I'm not sure that I understand your question correctly, but the reason for
> that is because foreign tables cannot have INSTEAD OF triggers.
Now I
Thanks a lot Heikki and Albe. Exactly what I was asking for.
Heikki: the libraries are written in languages that have their own runtime
and their documentation insists that both init and dispose calls are
performed when used from C. PG_init() and proc_exit sounds spot on.
Any ideas about keeping s
On 08/04/2014 12:54 PM, Seref Arikan wrote:
Greetings,
I hope this is the right group to ask this question; apologies if this
should go the general or some other list.
I have multiple shared libraries that can be called from C that I'd like to
use from a C based postgresql function.
These libra
Seref Arikan wrote:
> I hope this is the right group to ask this question; apologies if this should
> go the general or some
> other list.
>
>
> I have multiple shared libraries that can be called from C that I'd like to
> use from a C based
> postgresql function.
>
> These libraries perform s
Greetings,
I hope this is the right group to ask this question; apologies if this
should go the general or some other list.
I have multiple shared libraries that can be called from C that I'd like to
use from a C based postgresql function.
These libraries perform some expensive initialization and
This patch is pretty trivial.
Another slightly less trivial but more useful version.
The issue is that there are 3 definitions of modulo, two of which are fine
(Knuth floored division and Euclidian), and the last one much less useful.
Alas, C (%) & SQL (MOD) choose the bad definition:-( I
On 08/02/2014 09:43 PM, John Cochran wrote:
I took at look at the TODO list and got interested in the possible
optimization of the bcTruelen() function. Read the archived messages about
that subject and decided to see what could be done.
I tested the performance of 5 different versions of bcTrue
Re: Bruce Momjian 2014-07-29 <20140729094234.gc13...@momjian.us>
> On Fri, Jun 20, 2014 at 05:15:05PM +0200, Christoph Berg wrote:
> > Another nitpick here: What pg_upgrade outputs doesn't even work on
> > most systems, you need to ./analyze_new_cluster.sh or "sh
> > analyze_new_cluster.sh".
>
> W
Hi guys,
sorry if I jump in the middle of the conversation. I have been
reading with much interest all that's been said above. However, the
goal of this patch is to give users another possibility while
performing backups. Especially when large databases are in use.
I really like the proposal
Hello,
> > > Now drop the i_t1_pkey_1 and check the query plan again.
> > >
> > > drop index i_t1_pkey_1;
> > > explain (costs off, analyze off) select * from t,t1 where t.a=t1.a
> order by
> > > t1.a,t1.b,t1.c,t1.d;
> > >QUERY PLAN
> > > ---
35 matches
Mail list logo
