Re: [HACKERS] Our regex vs. POSIX on "longest match"

Brendan Jurd writes: > I am in the process of accelerating down the rabbit hole of regex > internals. Something that came up during my reading, is that a POSIX > compliant regex engine ought to always prefer the longest possible > match, when multiple matches are possible beginning from the same

[HACKERS] Our regex vs. POSIX on "longest match"

Hello folks, I am in the process of accelerating down the rabbit hole of regex internals. Something that came up during my reading, is that a POSIX compliant regex engine ought to always prefer the longest possible match, when multiple matches are possible beginning from the same location in the

Re: [HACKERS] Parameterized-path cost comparisons need some work

Robert Haas writes: > On Wed, Feb 29, 2012 at 6:01 PM, Tom Lane wrote: >> (... thinks some more ...) No, that doesn't get us there, because that >> doesn't establish that a more-parameterized path produces fewer rows >> than some path that requires less parameterization, yet not none at >> all.

Re: [HACKERS] Patch: improve selectivity estimation for IN/NOT IN

On Sun, Mar 4, 2012 at 2:38 AM, Tom Lane wrote: > Daniele Varrazzo writes: >> the attached patch improves the array selectivity estimation for = ANY >> and <> ALL, hence for the IN/NOT IN operators, to avoid the >> shortcoming described in >>

Re: [HACKERS] Patch: improve selectivity estimation for IN/NOT IN

Daniele Varrazzo writes: > the attached patch improves the array selectivity estimation for = ANY > and <> ALL, hence for the IN/NOT IN operators, to avoid the > shortcoming described in > . In connection with Alexander Korotk

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Sat, Mar 3, 2012 at 14:53, Simon Riggs wrote: > Thanks Noah for drawing attention to this thread. I hadn't been > watching. As you say, this work would allow me to freeze rows at load > time and avoid the overhead of hint bit setting, which avoids > performance issues from hint bit setting in c

Re: [HACKERS] poll: CHECK TRIGGER?

Excerpts from Tom Lane's message of sáb mar 03 23:00:26 -0300 2012: > Alvaro Herrera writes: > > Pavel's patch for CHECK FUNCTION is adding another command besides that > > one, which is CHECK TRIGGER. The idea behind this is that you give it > > the relation to which the trigger is attached in

Re: [HACKERS] poll: CHECK TRIGGER?

Alvaro Herrera writes: > Pavel's patch for CHECK FUNCTION is adding another command besides that > one, which is CHECK TRIGGER. The idea behind this is that you give it > the relation to which the trigger is attached in addition to the trigger > name, and it checks the function being called by th

Re: [HACKERS] Collect frequency statistics for arrays

Alexander Korotkov writes: > [ array statistics patch ] I've committed this after a fair amount of editorialization. There are still some loose ends to deal with, but I felt it was ready to go into the tree for wider testing. The main thing I changed that wasn't in the nature of cleanup/bugfixi

Re: [HACKERS] archive_keepalive_command

On Sun, Jan 15, 2012 at 5:52 PM, Simon Riggs wrote: > On Fri, Dec 16, 2011 at 3:01 PM, Simon Riggs wrote: >> archive_command and restore_command describe how to ship WAL files >> to/from an archive. >> >> When there is nothing to ship, we delay sending WAL files. When no WAL >> files, the standby

Re: [HACKERS] review: CHECK FUNCTION statement

Excerpts from Alvaro Herrera's message of sáb mar 03 17:56:23 -0300 2012: > Excerpts from Alvaro Herrera's message of sáb mar 03 16:54:19 -0300 2012: > > Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012: > > > > 3. THE ARE NOT CARET - this is really important > > > I am no

Re: [HACKERS] Memory usage during sorting

On Sun, Feb 26, 2012 at 7:20 PM, Robert Haas wrote: > On Sat, Feb 25, 2012 at 4:31 PM, Jeff Janes wrote: >>> I'm not sure about the conclusion, but given this discussion, I'm >>> inclined to mark this Returned with Feedback. >> >> OK, thanks.  Does anyone have additional feed-back on how tightly

Re: [HACKERS] review: CHECK FUNCTION statement

Excerpts from Alvaro Herrera's message of sáb mar 03 16:54:19 -0300 2012: > Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012: > > 3. THE ARE NOT CARET - this is really important > I am not sure about the caret thingy -- mainly because I don't think it > works all that well

[HACKERS] poll: CHECK TRIGGER?

Hi, Pavel's patch for CHECK FUNCTION is adding another command besides that one, which is CHECK TRIGGER. The idea behind this is that you give it the relation to which the trigger is attached in addition to the trigger name, and it checks the function being called by that trigger. IMHO having a

Re: [HACKERS] COPY with hints, rebirth

> Simon Riggs wrote: > Kevin Grittner wrote: >> Simon Riggs wrote: >> >>> I like Marti's idea. At present, making his idea work could >>> easily mean checksums sink >> For my part, improving bulk load performance and TRUNCATE >> transactional semantics would trump checksums > It doesn't look

[HACKERS] tuplesort memory usage: grow_memtuples

When sorting small tuples, the memtuples array can use a substantial fraction of the total per-tuple memory used. (In the case of pass by value, it is all of it) The way it grows leads to sub-optimal memory usage. In one case, if it can grow by 1.999 x, but not by 2 x, we just give up and use hal

Re: [HACKERS] COPY with hints, rebirth

On Fri, Mar 2, 2012 at 11:15 PM, Kevin Grittner wrote: > Simon Riggs wrote: > >> I like Marti's idea. At present, making his idea work could easily >> mean checksums sink, so not sure whether to attempt to make that >> work in detail. > > For my part, improving bulk load performance and TRUNCATE

Re: [HACKERS] review: CHECK FUNCTION statement

Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012: > Hello > > > > > It wasn't all that difficult -- see below.  While at this, I have a > > question: how attached you are to the current return format for CHECK > > FUNCTION? > > TupleDescr is created by language creator. Th

[HACKERS] Patch: improve selectivity estimation for IN/NOT IN

Hello, the attached patch improves the array selectivity estimation for = ANY and <> ALL, hence for the IN/NOT IN operators, to avoid the shortcoming described in . Cheers, -- Daniele From d10e60dd3dec340b96b372792e4a0650ec10

Re: [HACKERS] Command Triggers, patch v11

On 3 March 2012 19:25, Dimitri Fontaine wrote: > "Kevin Grittner" writes: >> Right.  What I thought I was agreeing with was the notion that you >> should need to specify more than the trigger name to drop the >> trigger.  Rather like how you can create a trigger AFTER INSERT OR >> UPDATE OR DELET

Re: [HACKERS] COPY with hints, rebirth

On Sat, Mar 3, 2012 at 1:14 PM, Simon Riggs wrote: > On Fri, Mar 2, 2012 at 8:58 PM, Noah Misch wrote: >> On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote: >>> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas >>> wrote: >>> > It's still broken: >> >> [BEGIN;TRUNCATE;SAVEPOINT;COPY;

Re: [HACKERS] review: CHECK FUNCTION statement

Excerpts from Petr Jelínek's message of sáb mar 03 10:26:04 -0300 2012: > On 03/03/2012 02:24 AM, Alvaro Herrera wrote: > > question: how attached you are to the current return format for CHECK > > FUNCTION? > > > > check function f1(); > > CHECK FUNCTION > > --

Re: [HACKERS] Command Triggers, patch v11

"Kevin Grittner" writes: > Right. What I thought I was agreeing with was the notion that you > should need to specify more than the trigger name to drop the > trigger. Rather like how you can create a trigger AFTER INSERT OR > UPDATE OR DELETE, but you don't need to specify all those events to >

Re: [HACKERS] Command Triggers, patch v11

Thom Brown wrote: > Don't you mean "shouldn't need to specify more than the trigger > name"? You are right, that's what I meant to say. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsq

Re: [HACKERS] Collect frequency statistics for arrays

... BTW, could you explain exactly how that "Fill histogram by hashtab" loop works? It's way too magic for my taste, and does in fact have bugs in the currently submitted patch. I've reworked it to this: /* Fill histogram by hashtab. */ delta = analyzed_rows - 1;

Re: [HACKERS] Command Triggers, patch v11

On 3 March 2012 16:12, Kevin Grittner wrote: >> Thom Brown  wrote: >> Dimitri Fontaine  wrote: >>> Thom Brown  writes: problem. It was the DROP COMMAND TRIGGER statement that garnered comment, as it makes more sense to drop the entire trigger than individual commands for that trigge

Re: [HACKERS] Command Triggers, patch v11

> Thom Brown wrote: > Dimitri Fontaine wrote: >> Thom Brown writes: >>> problem. It was the DROP COMMAND TRIGGER statement that garnered >>> comment, as it makes more sense to drop the entire trigger than >>> individual commands for that trigger. >> >> What you're saying here is that a single co

Re: [HACKERS] Command Triggers, patch v11

On 3 March 2012 14:34, Dimitri Fontaine wrote: > Thom Brown writes: >> problem.  It was the DROP COMMAND TRIGGER statement that garnered >> comment, as it makes more sense to drop the entire trigger than >> individual commands for that trigger. > > What you're saying here is that a single command

Re: [HACKERS] Command Triggers, patch v11

On 3 March 2012 14:26, Dimitri Fontaine wrote: > Thom Brown writes: >> And having tried building it, it appears to fail. > > Sorry about that, my compiler here was happy building the source (and I > had been doing make clean install along the way) and make installcheck > passed, here. > > Now fix

Re: [HACKERS] Command Triggers, patch v11

Thom Brown writes: > problem. It was the DROP COMMAND TRIGGER statement that garnered > comment, as it makes more sense to drop the entire trigger than > individual commands for that trigger. What you're saying here is that a single command could have more than one command attached to it, and wh

Re: [HACKERS] Command Triggers, patch v11

Thom Brown writes: > And having tried building it, it appears to fail. Sorry about that, my compiler here was happy building the source (and I had been doing make clean install along the way) and make installcheck passed, here. Now fixed on my github's branch, including docs. I'll send an updat

Re: [HACKERS] [v9.2] Add GUC sepgsql.client_label

On 2012-02-24 17:25, Yeb Havinga wrote: On 2012-02-23 12:17, Kohei KaiGai wrote: 2012/2/20 Yeb Havinga: On 2012-02-05 10:09, Kohei KaiGai wrote: The attached part-1 patch moves related routines from hooks.c to label.c because of references to static variables. The part-2 patch implements abov

Re: [HACKERS] Command Triggers, patch v11

On 3 March 2012 13:45, Dimitri Fontaine wrote: > Robert Haas writes:       CREATE COMMAND TRIGGER name ... properties ...;       DROP COMMAND TRIGGER name; full stop.  If you want to run the same trigger function on some more commands, add another trigger name. >>> >>> +1

Re: [HACKERS] Command Triggers, patch v11

Robert Haas writes: >>>       CREATE COMMAND TRIGGER name ... properties ...; >>>       DROP COMMAND TRIGGER name; >>> >>> full stop.  If you want to run the same trigger function on some >>> more commands, add another trigger name. >> >> +1 > > +1. I suggested the same thing a while back. Yeah,

Re: [HACKERS] review: CHECK FUNCTION statement

On 03/03/2012 02:24 AM, Alvaro Herrera wrote: question: how attached you are to the current return format for CHECK FUNCTION? check function f1(); CHECK FUNCTION - In function: 'f1()' error:42804:5:assignment

Re: [HACKERS] COPY with hints, rebirth

On Fri, Mar 2, 2012 at 8:58 PM, Noah Misch wrote: > On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote: >> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas >> wrote: >> > It's still broken: > > [BEGIN;TRUNCATE;SAVEPOINT;COPY;ROLLBACK TO] > >> So this approach isn't the one... >> >> Th

Re: [HACKERS] RFC: Making TRUNCATE more "MVCC-safe"

On Sat, Feb 11, 2012 at 4:46 AM, Noah Misch wrote: >> But I have to admit I'm intrigued by the idea of extending this to >> other cases, if there's a reasonable way to do that.  For example, if >> we could fix things up so that we don't see a table at all if it was >> created after we took our sn