-- Forwarded message --
From: Pavel Stehule
Date: 2010/11/18
Subject: Re: patch: format function, next generation
To: Jeff Janes
Kopie: pgsql-hackers-ow...@postgresql.org
Hello
somebody takes my oid :)
updated patch is in attachment
Regards
Pavel Stehule
2010/11/18 Jeff Jan
On Fri, Nov 19, 2010 at 11:40:05AM +0900, Itagaki Takahiro wrote:
> On Fri, Nov 19, 2010 at 08:33, David Fetter wrote:
> > In order to get WITH ORDINALITY, would it be better to change
> > gram.y to account for both WITH ORDINALITY and without, or just
> > for the WITH ORDINALITY case?
>
> We pro
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Alvaro Herrera :
>>> I fail to see how this supports the FOR-IN-array development though. It
>>> will just be another unused construct for most people, no?
>
>> maybe I don't understand well, but patch FOR-IN-ARRAY has a documentation
>
Gurjeet Singh wrote:
Seems like it would improve performance in general, but more so under
load conditions when you actually need it. I am not sure if -depth
option is supported by all incarnations of 'find'.
Given the way directory writes are cached by the filesystem, I'm not
sure why the lo
Robert Haas writes:
> I'm all in favor of having some memory ordering primitives so that we
> can try to implement better algorithms, but if we use it here it
> amounts to a fairly significant escalation in the minimum requirements
> to compile PG (which is bad) rather than just a performance
> op
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mi?? nov 17 13:04:46 -0300 2010:
>
> > OK, I doubt we want to add complexity to improve this, so I see our
> > options as:
> >
> > o ignore the problem
> > o display IPv4/IPv6 labels
> > o display only an IPv6 label
>
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mi?? nov 17 13:04:46 -0300 2010:
>
> > OK, I doubt we want to add complexity to improve this, so I see our
> > options as:
> >
> > o ignore the problem
> > o display IPv4/IPv6 labels
> > o display only an IPv6 label
>
Last month's new Linux kernel 2.6.36 includes a rewrite of the out of
memory killer:
http://lwn.net/Articles/391222/
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a63d83f427fbce97a6cea0db2e64b0eb8435cd10
The new "badness" method totals the task's RSS and swap
On Fri, Nov 19, 2010 at 08:33, David Fetter wrote:
> In order to get WITH ORDINALITY, would it be better to change gram.y
> to account for both WITH ORDINALITY and without, or just for the WITH
> ORDINALITY case?
We probably need to change gram.y and make UNNEST to be COL_NAME_KEYWORD.
UNNEST (wi
On Thu, Nov 18, 2010 at 5:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
>>> Hmm ... I just remembered the reason why we didn't use a spinlock in
>>> these functions already. Namely, that it's unsafe for a signal handler
>>> to try to acquire a
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> what is a slow:
>
>> a) repeated detoasting - access with subscripts - maybe detoasted
>> values can be cached?
>> b) evaluation of SRF expression - maybe call of SRF function can be
>> simple expression,
>> c) faster evaluation ro query
>
>> The mo
On 11/18/2010 06:06 PM, Andres Freund wrote:
Well, a good reason for that might be that unnest() is pretty new... Most code
I read has been initially written quite a bit earlier. Seeing 8.4 in
production is only starting to get common.
I guess we must have more adventurous customers than you
Folks,
I'd like to see about getting an enhanced UNNEST, first the one
according to the SQL standard, namely with an optional WITH ORDINALITY
clause, and possibly some extra enhancements.
In order to get WITH ORDINALITY, would it be better to change gram.y
to account for both WITH ORDINALITY and
On Thursday 18 November 2010 21:11:32 Alvaro Herrera wrote:
> Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
> > 2010/11/18 Andrew Dunstan :
> > >> I didn't say so nobody use it. You, me, David. But I really didn't see
> > >> this pattern here in real applications.
> > >
Pavel Stehule writes:
> 2010/11/18 Alvaro Herrera :
>> I fail to see how this supports the FOR-IN-array development though. Â It
>> will just be another unused construct for most people, no?
> maybe I don't understand well, but patch FOR-IN-ARRAY has a documentation
UNNEST is documented too. Ad
Robert Haas writes:
> On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
>> Hmm ... I just remembered the reason why we didn't use a spinlock in
>> these functions already. Namely, that it's unsafe for a signal handler
>> to try to acquire a spinlock that the interrupted code might be holding.
>
"Kevin Grittner" wrote:
> Jignesh Shah wrote:
>
>> The question is should the delete fail if it doesn't exist and
>> cause a rollback or succeed with DELETE 0 ?
>
> I think existing behavior is consistent with both the standard and
> the other behaviors of PostgreSQL at the READ COMMITTED iso
On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> In SetLatch, is it enough to add the SpinLockAcquire() call *after*
>> checking that is_set is not already set? Ie. still do the quick exit
>> without holding a lock. Or do we need a memory barrier operation before
2010/11/18 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
>> 2010/11/18 Andrew Dunstan :
>
>> >> I didn't say so nobody use it. You, me, David. But I really didn't see
>> >> this pattern here in real applications.
>> >>
>> >
>> > Lots of people are told
Excerpts from Pavel Stehule's message of jue nov 18 17:00:04 -0300 2010:
> 2010/11/18 Andrew Dunstan :
> >> I didn't say so nobody use it. You, me, David. But I really didn't see
> >> this pattern here in real applications.
> >>
> >
> > Lots of people are told to use it on IRC. Trust me, it's gett
2010/11/18 Andrew Dunstan :
>
>
> On 11/18/2010 02:39 PM, Pavel Stehule wrote:
>>
>> 2010/11/18 Andrew Dunstan:
>>>
>>> On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
>>>
>>> How on earth do you know that? I use it a lot
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> "unnest" returns all fields, but
>> these fields should not be used. There isn't possible to say - stop, I
>> don't need other fields. It's possible just with special PL statement,
>> because it is controlled by PL. So it is reason why I don't belie
On 11/18/2010 02:39 PM, Pavel Stehule wrote:
2010/11/18 Andrew Dunstan:
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I use it a lot and I was just demonstrating
it to a client yesterday, a
2010/11/18 Andrew Dunstan :
>
>
> On 11/18/2010 02:17 PM, Pavel Stehule wrote:
>>
>> -only a few people use FOR IN SELECT UNNEST for iteration over array.
>
> How on earth do you know that? I use it a lot and I was just demonstrating
> it to a client yesterday, and I'm quite sure he will use it a
On 15.11.2010 21:42, Peter Eisentraut wrote:
On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
I am checking a patch. I found a problem with initdb
Ah, late night brain farts, it appears. Here is a corrected version.
Some random comments:
In syntax.sgml:
+The COLLATE clause ove
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> this note was a different -only a few people use FOR IN SELECT UNNEST
>> for iteration over array. So from Robert's question (what is important
>> for current code?) perspective the more significant is access to
>> individual fields via subscripts.
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Tom Lane :
>>> The problem here is that FOR is a syntactic choke point: it's already
>>> overloaded with several different sub-syntaxes that are quite difficult
>>> to separate. Adding another one makes that worse, with the consequences
On 11/18/2010 02:17 PM, Pavel Stehule wrote:
-only a few people use FOR IN SELECT UNNEST for iteration over array.
How on earth do you know that? I use it a lot and I was just
demonstrating it to a client yesterday, and I'm quite sure he will use
it a lot too. I bet I'm far from alone.
c
On Thu, Nov 18, 2010 at 19:36, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Nov 18, 2010 at 19:21, Tom Lane wrote:
>>> I thought the proposal on the table was to add "peer" (or some other
>>> name) to refer to the unix-socket auth method, and use that term
>>> preferentially in the docs,
Pavel Stehule writes:
> "unnest" returns all fields, but
> these fields should not be used. There isn't possible to say - stop, I
> don't need other fields. It's possible just with special PL statement,
> because it is controlled by PL. So it is reason why I don't believe in
> optimizations on PL
Pavel Stehule writes:
> this note was a different -only a few people use FOR IN SELECT UNNEST
> for iteration over array. So from Robert's question (what is important
> for current code?) perspective the more significant is access to
> individual fields via subscripts. For example:
> for i in 1.
Alvaro Herrera writes:
> I have to say that I'm baffled as to why has_database_privilege et al
> were declared in builtins.h but pg_table_is_visible et al in dependency.c.
builtins.h is probably the right place, on the whole ... I agree that
consistency is somewhat lacking in this area.
Alvaro Herrera writes:
> I just noticed that this is leaking a bit of memory, because we call
> getObjectDescription (which pallocs its result) and then
> cstring_to_text which pallocs a copy. This is not a lot and it's not
> going to live much anyway, is it worrying about?
No. The extra string
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> what is a slow:
>
>> a) repeated detoasting - access with subscripts - maybe detoasted
>> values can be cached?
>> b) evaluation of SRF expression - maybe call of SRF function can be
>> simple expression,
>> c) faster evaluation ro query
>
>> The mo
Pavel Stehule writes:
> 2010/11/18 Tom Lane :
>> The problem here is that FOR is a syntactic choke point: it's already
>> overloaded with several different sub-syntaxes that are quite difficult
>> to separate. Â Adding another one makes that worse, with the consequences
>> that we might misinterpr
Excerpts from Tom Lane's message of jue nov 18 14:49:21 -0300 2010:
> Please do not do this:
>
> +/* this doesn't really need to appear in any header file */
> +Datumpg_describe_object(PG_FUNCTION_ARGS);
>
> Put the extern declaration in a header file, don't be cute.
Oh, I forgot to comment
On Thu, Nov 18, 2010 at 6:36 PM, Tom Lane wrote:
> It's also warning about the wrong thing. IMO the real subtext to this
> discussion is that we're afraid people are using ident-over-TCP
> insecurely because they've confused it with ident-over-socket.
> Which is a legitimate concern, but issuing
I just noticed that this is leaking a bit of memory, because we call
getObjectDescription (which pallocs its result) and then
cstring_to_text which pallocs a copy. This is not a lot and it's not
going to live much anyway, is it worrying about? I reworked it like
this:
{
char *descr
Pavel Stehule writes:
> what is a slow:
> a) repeated detoasting - access with subscripts - maybe detoasted
> values can be cached?
> b) evaluation of SRF expression - maybe call of SRF function can be
> simple expression,
> c) faster evaluation ro query
> The most important is @a.
Really? Bec
> We should've done that long ago - it's already used for things that
> aren't ident. If anything, it should be pg_usermap.conf.
That would be nice. How would we handle the backwards compatibility?
Accept pg_ident files also for 2 versions with a warning in the logs,
and then stop reading them?
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule
> wrote:
>> 2010/11/18 Robert Haas :
>>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
I would *much* rather we get the performance benefit by internal
optimization, and forego inventing syntax.
>>>
>>> +1.
>
On Thu, Nov 18, 2010 at 19:41, Josh Berkus wrote:
>
>>> I thought the proposal on the table was to add "peer" (or some other
>>> name) to refer to the unix-socket auth method, and use that term
>>> preferentially in the docs, while continuing to accept "ident" as an
>>> old name for it. Is that r
>> I thought the proposal on the table was to add "peer" (or some other
>> name) to refer to the unix-socket auth method, and use that term
>> preferentially in the docs, while continuing to accept "ident" as an
>> old name for it. Is that really too confusing?
What about the pg_ident file? Are
On 11/18/2010 01:21 PM, Tom Lane wrote:
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?
No
Magnus Hagander writes:
> On Thu, Nov 18, 2010 at 19:21, Tom Lane wrote:
>> I thought the proposal on the table was to add "peer" (or some other
>> name) to refer to the unix-socket auth method, and use that term
>> preferentially in the docs, while continuing to accept "ident" as an
>> old name
On Thu, Nov 18, 2010 at 19:21, Tom Lane wrote:
> Josh Berkus writes:
>>> We use it. Do you have an alternative that doesn't lower security
>>> besides Kerberos? Anti-ident arguments are straw man arguments - "If
>>> you setup identd badly or don't trust remote root or your network,
>>> ident suck
Josh Berkus writes:
>> We use it. Do you have an alternative that doesn't lower security
>> besides Kerberos? Anti-ident arguments are straw man arguments - "If
>> you setup identd badly or don't trust remote root or your network,
>> ident sucks as an authentication mechanism".
> Actually, you're
On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule wrote:
> 2010/11/18 Robert Haas :
>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
>>> I would *much* rather we get the performance benefit by internal
>>> optimization, and forego inventing syntax.
>>
>> +1.
>
> any optimization will be about 10
On Thu, Nov 18, 2010 at 1:01 PM, Josh Berkus wrote:
>
>> We use it. Do you have an alternative that doesn't lower security
>> besides Kerberos? Anti-ident arguments are straw man arguments - "If
>> you setup identd badly or don't trust remote root or your network,
>> ident sucks as an authenticati
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
>> I would *much* rather we get the performance benefit by internal
>> optimization, and forego inventing syntax.
>
> +1.
any optimization will be about 10-20% slower than direct access. See
my tests: on large arrays isn
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".
Actually, you're trusting that nobody can add t
2010/11/18 Tom Lane :
> Andrew Dunstan writes:
>> Syntactic sugar is not entirely to be despised, anyway.
>
> If it were harmless syntactic sugar I wouldn't be objecting so loudly.
> The problem here is that FOR is a syntactic choke point: it's already
> overloaded with several different sub-synta
On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane wrote:
> I would *much* rather we get the performance benefit by internal
> optimization, and forego inventing syntax.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing li
Alvaro Herrera writes:
> In the process of looking it over again, I noticed that in an
> assert-enabled build, it's trivial to crash the server with this
> function: just pass a nonzero subobjid with an object class that doesn't
> take one. This could be fixed easily by turning the Asserts into
>
2010/11/18 Tom Lane :
> Pavel Stehule writes:
>> 2010/11/18 Tom Lane :
>>> More to the point, if there is indeed an interesting performance win
>>> here, we could get the same win by internally optimizing the existing
>>> syntax.
>
>> sorry, but I don't agree. I don't think, so there are some big
Andrew Dunstan writes:
> Syntactic sugar is not entirely to be despised, anyway.
If it were harmless syntactic sugar I wouldn't be objecting so loudly.
The problem here is that FOR is a syntactic choke point: it's already
overloaded with several different sub-syntaxes that are quite difficult
to
On Thu, Nov 18, 2010 at 10:45 AM, Marko Tiikkaja
wrote:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan qual
> filtered from a node's input. The output looks like this:
I have wished for this many, MANY times.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
Thanks for the comments. Updated patch attached.
In the process of looking it over again, I noticed that in an
assert-enabled build, it's trivial to crash the server with this
function: just pass a nonzero subobjid with an object class that doesn't
take one. This could be fixed easily by turnin
Pavel Stehule writes:
> 2010/11/18 Tom Lane :
>> More to the point, if there is indeed an interesting performance win
>> here, we could get the same win by internally optimizing the existing
>> syntax.
> sorry, but I don't agree. I don't think, so there are some big space
> for optimizing - and i
On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input. The output looks like this:
If it supports the same for index-scans I *really
On Thursday 18 November 2010 17:48:43 Marko Tiikkaja wrote:
> On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
> > On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> >> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> >
> >> qual filtered from a node's input.
On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> Hi,
>
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input. The output looks like this:
If it supports the same for index-scans I *really* like it and even proposed a
patch earl
2010/11/18 Tom Lane :
> Merlin Moncure writes:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>>> Yes, which begs the question of why bother at all.
>
>> Pavel's performance argument is imnsho valid.
>
> Well, that argument is unsupported by any evidence, so far as I've seen.
>
> More to th
On 2010-11-18 6:26 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input.
I don't like this a whole lot. It's unclear what "filtered" means,
or why it's worth expending precious EXPLAIN ANALY
Marko Tiikkaja writes:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input.
I don't like this a whole lot. It's unclear what "filtered" means,
or why it's worth expending precious EXPLAIN ANALYZE output space for.
Also, you've not imple
Merlin Moncure writes:
> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>> Yes, which begs the question of why bother at all.
> Pavel's performance argument is imnsho valid.
Well, that argument is unsupported by any evidence, so far as I've seen.
More to the point, if there is indeed an int
2010/11/18 Pavel Stehule :
> 2010/11/18 Cédric Villemain :
>> 2010/11/18 Robert Haas :
>>> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> w
On 11/18/2010 10:33 AM, Robert Haas wrote:
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
Pavel's performance argument is imnsho valid. arrays at present are
the best way to pass data around functions and any optimizations here
are very welcome. Given that, is there any way to miti
2010/11/18 Cédric Villemain :
> 2010/11/18 Robert Haas :
>> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
> wrote:
>> i will start the revie
Thanks once again Mr. Heikki for your help. Got your point!
Thanks :)
-Vaibhav (*_*)
On Thu, Nov 18, 2010 at 7:10 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 18.11.2010 15:19, Vaibhav Kaushal wrote:
>
>> I have a small problem: Suppose that I have a table in Postgr
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry
2010/11/18 Robert Haas :
> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
>> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry
Hi,
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input. The output looks like this:
QUERY PLAN
-
On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure wrote:
> On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>>> wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit
2010/11/18 Pavel Stehule :
> 2010/11/18 Cédric Villemain :
>> 2010/11/18 Pavel Stehule :
>>> 2010/11/18 Tom Lane :
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
> wrote:
>> i will start the review of this one... but before that sorry for
>> suggest
On Thu, Nov 18, 2010 at 3:07 AM, Dimitri Fontaine
wrote:
>
>> CREATE VOLATILE TABLE blow_me_away (k text, v text) SOME OTHER WORDS
>> THAT EXPLAIN THE DETAILS GO HERE;
>
> [ TRUNCATE ON RESTART ]
>
> Your patch implements this option, right?
Yeah.
--
Robert Haas
EnterpriseDB: http://www.enterpr
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> wrote:
>>> i will start the review of this one... but before that sorry for
>>> suggesting this a bit later but about using UNNEST as part of the
>>> sintax?
>
>> Doe
Excerpts from Bruce Momjian's message of mié nov 17 13:04:46 -0300 2010:
> OK, I doubt we want to add complexity to improve this, so I see our
> options as:
>
> o ignore the problem
> o display IPv4/IPv6 labels
> o display only an IPv6 label
> o something else
I think we shou
2010/11/18 Cédric Villemain :
> 2010/11/18 Pavel Stehule :
>> 2010/11/18 Tom Lane :
>>> Merlin Moncure writes:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
wrote:
> i will start the review of this one... but before that sorry for
> suggesting this a bit later but about using
On 18.11.2010 15:19, Vaibhav Kaushal wrote:
I have a small problem: Suppose that I have a table in PostgreSQL which has
a integer field as its Primary key and I have used the Hash indexing method
for creating the index for the field on the table. Now I want to know the
following details about the
Hi all,
I have a small problem: Suppose that I have a table in PostgreSQL which has
a integer field as its Primary key and I have used the Hash indexing method
for creating the index for the field on the table. Now I want to know the
following details about the index (assuming the machine running
On 17.11.2010 19:36, Teodor Sigaev wrote:
Hmm, will have to do some benchmarking on that. I'm using the Consistent
function when walking down to check if the downlink needs to be updated,
and assumed that it would be insignificant compared to the cost of
calling Penalty on all the keys on the pag
On Tue, Nov 16, 2010 at 10:49 AM, Robert Haas wrote:
>> Just in a quick scan, I don't have any objection to v2 except that the
>> protocol documentation is lacking.
>
> OK, I'll mark it Waiting on Author pending that issue.
The patch is touching protocol.sgml as follows. Isn't this enough?
-
2010/11/18 Pavel Stehule :
> 2010/11/18 Tom Lane :
>> Merlin Moncure writes:
>>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>>> wrote:
i will start the review of this one... but before that sorry for
suggesting this a bit later but about using UNNEST as part of the
sintax?
>>
> CREATE VOLATILE TABLE blow_me_away (k text, v text) SOME OTHER WORDS
> THAT EXPLAIN THE DETAILS GO HERE;
[ TRUNCATE ON RESTART ]
Your patch implements this option, right?
Regards,
>
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 18.11.2010 08:12, Shigeru HANADA wrote:
When I was reading vacuum.c, I found that the parameter 'stmttype' of
get_rel_oids() is not used at all. The parameter had been used as
command tag in the notice message about "invalid object type", but now
such messages are reported by other functions.
86 matches
Mail list logo
