Hi,
Le lundi 19 janvier 2009, Tom Lane a écrit :
> But having said that: 8.4 will provide a standard trigger that
> short-circuits vacuous updates, which you can apply to tables in which
> you think vacuous updates are likely. It's your responsibility to place
> the trigger so that it doesn't int
the only difference here is, that the trigger will memcmp (compare)
all data. Say, if we have two columns, int and bytea, and just want to
compare fist one - it will use a lot of cpu in vain.
I have to say, it is a shame sometimes - that trigger isn't aware of
what fields we do update exactly
--
On Sun, 18 Jan 2009 22:12:07 +0100
Ivan Sergio Borgonovo wrote:
> I've to apply a discounts to products.
>
> For each promotion I've a query that select a list of products and
> should apply a discount.
>
> Queries may have intersections, in these intersections the highest
> discount should be
On Mon, Jan 19, 2009 at 09:48, Grzegorz Jaśkiewicz wrote:
> On Mon, Jan 19, 2009 at 4:43 PM, Tom Lane wrote:
>> But having said that: 8.4 will provide a standard trigger that
>> short-circuits vacuous updates, which you can apply to tables in which
>> you think vacuous updates are likely. It's y
On Mon, Jan 19, 2009 at 4:43 PM, Tom Lane wrote:
> But having said that: 8.4 will provide a standard trigger that
> short-circuits vacuous updates, which you can apply to tables in which
> you think vacuous updates are likely. It's your responsibility to place
> the trigger so that it doesn't int
"Scott Marlowe" writes:
> But seriously, it's doing what you told it to do. There might be
> corner cases where you need a trigger to fire for a row on change, and
> short-circuiting could cause things to fail in unexpected ways.
The other argument against doing this by default is that with
non-s
On Sun, 18 Jan 2009 19:44:40 -0700
"Scott Marlowe" wrote:
> You could update returning rowsupdated, so you could run that and
> get a list of all the rows that were updated. Then build a simple
> select where not in (those rows) to get the rest for inserting.
uh nice addition. I didn't check al
2009/1/19 Scott Marlowe :
> Yes, but what about a table with an update trigger on it that does
> some interesting bit of housekeeping when rows are updated?
exactly, that's another one of reasons why I wouldn't write that patch :P
> It's a prime example of fixing a problem created by not knowing
On Mon, Jan 19, 2009 at 12:53 AM, Grzegorz Jaśkiewicz wrote:
> 2009/1/19 Scott Marlowe :
>> Submit a patch. :)
>>
>> But seriously, it's doing what you told it to do. There might be
>> corner cases where you need a trigger to fire for a row on change, and
>> short-circuiting could cause things to
2009/1/19 Scott Marlowe :
> Submit a patch. :)
>
> But seriously, it's doing what you told it to do. There might be
> corner cases where you need a trigger to fire for a row on change, and
> short-circuiting could cause things to fail in unexpected ways.
as far as my little knowledge about pg goes
On Mon, Jan 19, 2009 at 12:12 AM, Grzegorz Jaśkiewicz wrote:
> On Mon, Jan 19, 2009 at 2:44 AM, Scott Marlowe
> wrote:
>> Watch out for bloat when doing this. A simple where change of
>>
>> update table set b = 45 ;
>>
>> to
>>
>> update table set b = 45 where b <> 45 ;
>>
>> can save the db a
On Mon, Jan 19, 2009 at 2:44 AM, Scott Marlowe wrote:
> Watch out for bloat when doing this. A simple where change of
>
> update table set b = 45 ;
>
> to
>
> update table set b = 45 where b <> 45 ;
>
> can save the db a lot of work, and if you can apply the same logic to
> your update to save so
On Sun, Jan 18, 2009 at 2:12 PM, Ivan Sergio Borgonovo
wrote:
> I've to apply a discounts to products.
>
> For each promotion I've a query that select a list of products and
> should apply a discount.
>
> Queries may have intersections, in these intersections the highest
> discount should be appli
Jan 2009 22:12:07 +0100
> From: m...@webthatworks.it
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] left join with smaller table or index on (XXX is not null)
> to avoid upsert
>
> I've to apply a discounts to products.
>
> For each promotion I've a que
I've to apply a discounts to products.
For each promotion I've a query that select a list of products and
should apply a discount.
Queries may have intersections, in these intersections the highest
discount should be applied.
Since queries may be slow I decided to proxy the discount this way:
c
15 matches
Mail list logo
