I'm having trouble finding documentation about how to write event
triggers. The chapter in the documentation
http://www.postgresql.org/docs/devel/static/event-triggers.html
says they can be written in C or supported PLs, but does not explain it
any further. Is there any documentation for it?
On Mon, Apr 15, 2013 at 04:41:53PM -0400, Andrew Dunstan wrote:
>
> On 04/15/2013 11:46 AM, Andres Freund wrote:
> >>
> >>Me either. It's an oversight, really. Unless there is any objection I'll
> >>change them toot sweet. What about the existing (as of 9.2) functions?
> >ISTM json_in, out, recv,
On Mon, Apr 15, 2013 at 7:51 PM, Tom Lane wrote:
> Rodrigo Barboza writes:
> > I created a implic cast for mytype to bigint.
> > So when I do the same query it does seq scan, because the column is
> > transformed into bigint.
>
> Yeah. One reason why there's not an unsigned int type already is
Rodrigo Barboza writes:
> I created a implic cast for mytype to bigint.
> So when I do the same query it does seq scan, because the column is
> transformed into bigint.
Yeah. One reason why there's not an unsigned int type already is that
it seems impossible to shoehorn it into the numeric promo
Andrew Dunstan schrieb:
>
>On 04/15/2013 11:46 AM, Andres Freund wrote:
>>>
>>> Me either. It's an oversight, really. Unless there is any objection
>I'll
>>> change them toot sweet. What about the existing (as of 9.2)
>functions?
>> ISTM json_in, out, recv, send should also be immutable.
>array
On 15 April 2013 21:32, Jaime Casanova wrote:
> On Mon, Apr 15, 2013 at 3:21 PM, Tom Lane wrote:
>>
>> OTOH, the notion that a UUID generator doesn't touch *any* database
>> state seems like it might be worth treating as a general function
>> property: it's simple to understand and applies to a l
On Mon, Apr 15, 2013 at 5:33 PM, Tom Lane wrote:
> Rodrigo Barboza writes:
> > I created a type 'mytype' (an unsigned int) and created an operator class
> > for index.
> > Then I created a table with a column of my type and isnerted 1000
> entries.
> > But no matter how many entries I have in th
On 04/15/2013 11:46 AM, Andres Freund wrote:
Me either. It's an oversight, really. Unless there is any objection I'll
change them toot sweet. What about the existing (as of 9.2) functions?
ISTM json_in, out, recv, send should also be immutable. array_to_json,
row_to_json et all can't be tho.
On Mon, Apr 15, 2013 at 4:21 PM, Tom Lane wrote:
> I think plenty of people would be upset if row serial numbers assigned
> with nextval() were not assigned in the order of the incoming rows.
> The argument that you can get gaps in the sequence in some corner cases
> (none of which apply within a
On 15 April 2013 20:52, Robert Haas wrote:
> On Mon, Apr 15, 2013 at 11:49 AM, Tom Lane wrote:
>>> I claim this is a common class, since sequence next_val functions and
>>> uuid generators meet that criteria and most common forms of auditing
>>> trigger, as well as any other form of data-reformat
Rodrigo Barboza writes:
> I created a type 'mytype' (an unsigned int) and created an operator class
> for index.
> Then I created a table with a column of my type and isnerted 1000 entries.
> But no matter how many entries I have in the table, it never uses the
> index. It always does a seq scan.
On Mon, Apr 15, 2013 at 3:21 PM, Tom Lane wrote:
>
> OTOH, the notion that a UUID generator doesn't touch *any* database
> state seems like it might be worth treating as a general function
> property: it's simple to understand and applies to a lot of other
> volatile functions such as random() and
On Mon, Apr 15, 2013 at 3:08 PM, Rodrigo Barboza
wrote:
>
> Here is the explain analyze with 1000 entries:
>
> explain analyze select * from mytable where a > 120::mytype and a <
> 530::mytype;
>
I'm not sure this is appropiate for -hackers, maybe should post on -general.
Also provide scripts wit
Robert Haas writes:
> On Mon, Apr 15, 2013 at 11:49 AM, Tom Lane wrote:
>> I don't believe that it's a good idea to consider nextval() to be
>> reorderable, so I'm not convinced by your argument here.
> Why not?
> I admit that I can't convince myself that it's safe. But I can't
> think of a co
On Fri, Apr 12, 2013 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> The hunk that changes the messages might need some thought so that it
>> doesn't cause a translation regression. But in general I see no
>> reason not to do this before we release beta1. It seems safe enough,
>> and chang
Hi guys.
I created a type 'mytype' (an unsigned int) and created an operator class
for index.
Then I created a table with a column of my type and isnerted 1000 entries.
But no matter how many entries I have in the table, it never uses the
index. It always does a seq scan.
Here is the explain analy
On Mon, Apr 15, 2013 at 11:49 AM, Tom Lane wrote:
>> I claim this is a common class, since sequence next_val functions and
>> uuid generators meet that criteria and most common forms of auditing
>> trigger, as well as any other form of data-reformatting trigger.
>
> I don't believe that it's a goo
On Mon, Apr 15, 2013 at 07:04:55PM +0100, Simon Riggs wrote:
> On 15 April 2013 18:41, David Fetter wrote:
>
> > The difference between HEAD and patch in the "COPY, with sequence"
> > case is pretty remarkable. What's the patch?
>
> Attached.
Thanks! :)
> This is usable only for this test. It
On 15 April 2013 18:41, David Fetter wrote:
> The difference between HEAD and patch in the "COPY, with sequence"
> case is pretty remarkable. What's the patch?
Attached.
This is usable only for this test. It is not anywhere remotely close
to being applied.
--
Simon Riggs ht
On Mon, Apr 15, 2013 at 06:30:55PM +0100, Simon Riggs wrote:
> On 15 April 2013 17:04, Simon Riggs wrote:
>
> > I will implement as a kluge, test and report the results.
>
> Test is COPY 1 million rows on a table with 2 columns, both bigint.
> Verified no checkpoints triggered during load.
> No
On 15 April 2013 17:04, Simon Riggs wrote:
> I will implement as a kluge, test and report the results.
Test is COPY 1 million rows on a table with 2 columns, both bigint.
Verified no checkpoints triggered during load.
No other work active on database, tests condicted on laptop
Autovacuum disable
Alexander Korotkov writes:
> I found you committed GiST index implementation. That's cool.
> I found an easy way to optimize it. We can also use trigramsMatchGraph for
> signatures. Attached patch contains implementation.
Good idea, committed.
regards, tom lane
--
Sent
David Fetter writes:
> On Mon, Apr 15, 2013 at 05:04:16PM +0100, Simon Riggs wrote:
>> Loading data into a table with a SERIAL or UUID column is the main
>> use case, so I'll measure that.
> The former is common enough a use case to optimize specifically,
> should the numbers come out right.
Yea
On 04/15/2013 06:04 PM, Simon Riggs wrote:
On 15 April 2013 16:55, Tom Lane wrote:
Simon Riggs writes:
On 15 April 2013 16:24, David Fetter wrote:
Do you have numbers on this, or ways to gather same? In other words,
how do we know what resources (time, CPU cycles, disk seeks, etc.) are
bei
On 15 April 2013 17:08, David Fetter wrote:
>> Loading data into a table with a SERIAL or UUID column is the main
>> use case, so I'll measure that.
>
> The former is common enough a use case to optimize specifically,
> should the numbers come out right. Do you suppose that an in-core
> UUID gen
On Mon, Apr 15, 2013 at 05:04:16PM +0100, Simon Riggs wrote:
> On 15 April 2013 16:55, Tom Lane wrote:
> > Simon Riggs writes:
> >> On 15 April 2013 16:24, David Fetter wrote:
> >>> Do you have numbers on this, or ways to gather same? In other
> >>> words, how do we know what resources (time, C
On Mon, Apr 15, 2013 at 11:49:42AM -0400, Tom Lane wrote:
> Simon Riggs writes:
> > COPY cannot be optimised correctly if we have before triggers or
> > volatile default expressions.
>
> > The multi-insert code detects those cases and falls back to the single
> > row mechanism in those cases.
>
On 15 April 2013 16:55, Tom Lane wrote:
> Simon Riggs writes:
>> On 15 April 2013 16:24, David Fetter wrote:
>>> Do you have numbers on this, or ways to gather same? In other words,
>>> how do we know what resources (time, CPU cycles, disk seeks, etc.) are
>>> being consumed here?
>
>> The mult
Simon Riggs writes:
> On 15 April 2013 16:24, David Fetter wrote:
>> Do you have numbers on this, or ways to gather same? In other words,
>> how do we know what resources (time, CPU cycles, disk seeks, etc.) are
>> being consumed here?
> The multi-insert optimisation for COPY is already there a
On 15 April 2013 16:41, Heikki Linnakangas wrote:
>> What I'd like to do is to invent a new form of labelling that allows
>> us to understand that COPY can still be optimised.
>
> It would be even nicer to detect at runtime, when a default expression or
> before trigger tries to access the same t
Simon Riggs writes:
> COPY cannot be optimised correctly if we have before triggers or
> volatile default expressions.
> The multi-insert code detects those cases and falls back to the single
> row mechanism in those cases.
> There a common class of volatile functions that wouldn't cause
> probl
On 15 April 2013 16:24, David Fetter wrote:
>> I claim this is a common class, since sequence next_val functions and
>> uuid generators meet that criteria and most common forms of auditing
>> trigger, as well as any other form of data-reformatting trigger. Since
>> this is a common case, it seems
On 2013-04-15 11:31:39 -0400, Andrew Dunstan wrote:
>
> On 04/15/2013 11:16 AM, hubert depesz lubaczewski wrote:
> >In current 9.3, I see:
> >
> >$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on
> >p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json'
Andrew Dunstan writes:
>> Is there any particular reason extract functions
>> (object_field/array_element/...) can't be immutable?
>>
>> I can't readily imagine a situation where output of these functions would
>> change for different queries.
> Me either. It's an oversight, really. Unless there
On 15.04.2013 17:00, Simon Riggs wrote:
COPY cannot be optimised correctly if we have before triggers or
volatile default expressions.
The multi-insert code detects those cases and falls back to the single
row mechanism in those cases.
There a common class of volatile functions that wouldn't ca
On Mon, Apr 15, 2013 at 11:31:39AM -0400, Andrew Dunstan wrote:
> Me either. It's an oversight, really. Unless there is any objection
> I'll change them toot sweet. What about the existing (as of 9.2)
> functions?
I don't think that 9.2 functions are that interesting, since these are
to build json
On 04/15/2013 11:16 AM, hubert depesz lubaczewski wrote:
In current 9.3, I see:
$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on
p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json';
proname | provolatile
--
On Mon, Apr 15, 2013 at 05:53:41PM +0400, Alexander Korotkov wrote:
> I found you committed GiST index implementation. That's cool.
> I found an easy way to optimize it. We can also use trigramsMatchGraph for
> signatures. Attached patch contains implementation.
> Simple example in order to demonst
On Mon, Apr 15, 2013 at 03:00:34PM +0100, Simon Riggs wrote:
> COPY cannot be optimised correctly if we have before triggers or
> volatile default expressions.
>
> The multi-insert code detects those cases and falls back to the
> single row mechanism in those cases.
>
> There a common class of vo
In current 9.3, I see:
$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on
p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json';
proname | provolatile
---+-
json_in | s
json_out
COPY cannot be optimised correctly if we have before triggers or
volatile default expressions.
The multi-insert code detects those cases and falls back to the single
row mechanism in those cases.
There a common class of volatile functions that wouldn't cause
problems: any volatile function that d
I found you committed GiST index implementation. That's cool.
I found an easy way to optimize it. We can also use trigramsMatchGraph for
signatures. Attached patch contains implementation.
Simple example in order to demonstrate it:
Before the patch:
test=# explain (analyze, buffers) select * from
On Apr14, 2013, at 17:56 , Fujii Masao wrote:
> At fast shutdown, after walsender sends the checkpoint record and
> closes the replication connection, walreceiver can detect the close
> of connection before receiving all WAL records. This means that,
> even if walsender sends all WAL records, walr
43 matches
Mail list logo
