"David E. Wheeler" writes:
> On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
>> Well, actually, I just committed it. If you want to test, feel free.
>> Note that right now only the anyarray && <@ @> operators are genuinely
>> fixed ... I plan to hack on tsearch and contrib pretty soon though.
> Hrm,
Heikki Linnakangas writes:
> On 21.12.2010 20:00, Heikki Linnakangas wrote:
>> One final version, with a bug fix wrt. root page split and some cleanup.
>> I'm planning to commit this before Christmas. It's a big patch, so
>> review would be much appreciated.
> Committed. Phew! Review & testing is
Robert Haas wrote:
> Well, my first thought is - I'm not sure it's realistic to think
> we're going to get this committed to 9.1.
>
> But that's not a very helpful thought. I just don't know who is
> going to review 7700 lines of code in the next month, and it
> doesn't sound like it can be deco
On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii wrote:
> While looking at the backend code, I realized that error code for
> "terminating connection due to conflict with recovery" is
> ERRCODE_ADMIN_SHUTDOWN.
>
> I thought the error code is for somewhat a human interruption, such as
> shutdown comman
On Sat, Jan 8, 2011 at 4:10 PM, Kevin Grittner
wrote:
> Splitting out those three would leave src/backend/ and src/include/
> which comes in at a svelte 5891 lines.
>
> With a little more work I could split the three new files
> (predicate.c, predicate.h, and predicate_internals.h) out from the
>
On Sat, Jan 8, 2011 at 9:12 PM, Jeff Davis wrote:
>> Oh, hmm. What generic functions did you have in mind?
>
> Well, input/output, comparisons, overlaps, intersection, minus, and all
> the necessary GiST support functions.
>
> Without generic functions, the only choices we have are:
> * force th
On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote:
> On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis wrote:
> > On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
> >> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
> >> > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> >> > inc
On Sat, Jan 8, 2011 at 8:02 PM, Joel Jacobson wrote:
> 2011/1/9 Robert Haas :
>> Oops. I misread your query. I thought the duplicates were because
>> you were feeding pg_describe_object the same classoid, objoid,
>> objsubid pair more than once, but I see now that's not the case (UNION
>> != UNI
On Sat, Jan 8, 2011 at 6:06 PM, Jeff Davis wrote:
> If we use timestamps, then that's 8 bytes each, meaning 16 bytes. Then,
> there is the VARHDRSZ (now we're at 20), the flag byte (21), and the
> range type oid (25). With alignment (if it's aligned at all), that's
> either 28 or 32 bytes, which i
On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis wrote:
> On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
>> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
>> > Any ideas? Maybe, with alignment and a "flags" byte (to hold
>> > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't
On Sat, Jan 8, 2011 at 4:28 PM, Stephen Frost wrote:
> Thoughts?
Unfortunately, we've officially exceeded my level of knowledge to the
point where I can't comment intelligently. Sorry :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
2011/1/9 Robert Haas :
> Oops. I misread your query. I thought the duplicates were because
> you were feeding pg_describe_object the same classoid, objoid,
> objsubid pair more than once, but I see now that's not the case (UNION
> != UNION ALL).
Ah, I see, yes, the query should actually be UNION
2011/1/9 Andreas Karlsson :
> Here is a patch, but I am not sure I am not sure if I like my idea for
> format. What do you think?
>
> SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
> FROM pg_amproc WHERE oid IN (10608,10612);
> pg_de
Here is a patch, but I am not sure I am not sure if I like my idea for
format. What do you think?
SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
FROM pg_amproc WHERE oid IN (10608,10612);
pg_describe_object
On Sat, Jan 8, 2011 at 4:21 PM, Joel Jacobson wrote:
> 2011/1/8 Robert Haas :
>> I don't think your analysis is correct. Each entry in pg_depend
>> represents the fact that one object depends on another object, and an
>> object could easily depend on more than one other object, or be
>> depended
On Sat, 2011-01-08 at 22:21 +0100, Joel Jacobson wrote:
> 2011/1/8 Robert Haas :
> > I don't think your analysis is correct. Each entry in pg_depend
> > represents the fact that one object depends on another object, and an
> > object could easily depend on more than one other object, or be
> > dep
On Sat, 2011-01-08 at 13:05 -0800, Jeff Davis wrote:
> On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
> > On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
> > > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> > > inclusivity, infinite boundaries, etc.), the extra 4 bytes doe
"David E. Wheeler" writes:
> On Jan 8, 2011, at 1:59 PM, Tom Lane wrote:
>> There seem to be three ways
>> in which intarray is simpler/faster than the generic operators:
>>
>> * restricted to integer arrays
>> * restricted to 1-D arrays
>> * doesn't allow nulls in the arrays
> My understanding
I updated my patch to make it use full index scan in GIN index which is
possible thanks to recent Tom Lane patch. Now wildcard, where no trigram can
be extracted from, invokes full index scan, which is slow but correct.
test=# explain (analyze, buffers) select * from words where word ilike
'%in%';
On Jan 8, 2011, at 1:59 PM, Tom Lane wrote:
>> Hrm, the queries I wrote for this sort of thing use intarray:
>
> I'm going to work on contrib/intarray first (before tsearch etc)
> so that you can do whatever testing you want sooner.
No, of course not.
> One of the things that first got me annoy
"David E. Wheeler" writes:
> On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
>> Well, actually, I just committed it. If you want to test, feel free.
>> Note that right now only the anyarray && <@ @> operators are genuinely
>> fixed ... I plan to hack on tsearch and contrib pretty soon though.
> Hrm,
All,
Alright, so, the whole fn_extra stuff seems to be unrelated.. I'm not
sure when it's used (perhaps multiple calls to the same function in a
given query?), but the PLs have their own hash tables that they use for
storing functions that have been called. I had assumed that was done
through fm
2011/1/8 Robert Haas :
> I don't think your analysis is correct. Each entry in pg_depend
> represents the fact that one object depends on another object, and an
> object could easily depend on more than one other object, or be
> depended upon by more than one other object, or depend on one object
I just finished implementing the SLRU techniques to limit shared
memory usage and provide graceful degradation under pessimal loads
(as suggested by Heikki), Dan seems to be wrapping up work on
preventing non-serializable transactions from being rolled back with
a serialization failure if they spli
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
> > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
> > much, anyway?
>
> I'd be really reluctant to b
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
> Any ideas? Maybe, with alignment and a "flags" byte (to hold
> inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
> much, anyway?
I'd be really reluctant to bloat the range representation by 4 bytes
to support an anyrange ty
On Sat, Jan 8, 2011 at 12:41 PM, Joel Jacobson wrote:
> The query below should not return any rows, because if it does, then
> there are oids with non-unique descriptions.
I don't think your analysis is correct. Each entry in pg_depend
represents the fact that one object depends on another objec
When writing the generic range output function, it needs to know the
specific range type in order to call the subtype's output function.
Records accomplish this by using a special cache based on the typmod,
apparently, which looks like a hack to me.
Arrays accomplish this by storing the specific
In my first attached, applied patch, I have found a way to speed
relations lookups in pg_upgrade. I knew there was a way to optimize
this but it was not clear until my major cleanups. Instead of doing
effectively a nested loop join on old/new relations, I now order them
and use a 1:1 mergejoin.
2011/1/8 Magnus Hagander :
> Yes. Once things are committed to the main repository, they are only
> backed out if someone finds a major issue with them that is not
> fixable (ina reasonable timeframe). That almost never happens. We
> don't keep unapproved patches or development branches in the main
On Thu, Jan 6, 2011 at 23:57, Heikki Linnakangas
wrote:
>
> Looks like pg_streamrecv creates the pg_xlog and pg_tblspc directories,
> because they're not included in the streamed tar. Wouldn't it be better to
> include them in the tar as empty directories at the server-side? Otherwise
> if you wri
While looking at the backend code, I realized that error code for
"terminating connection due to conflict with recovery" is
ERRCODE_ADMIN_SHUTDOWN.
I thought the error code is for somewhat a human interruption, such as
shutdown command issued by pg_ctl. Is the usage of the error code
appropreate?
On Tue, Jan 4, 2011 at 9:41 PM, Robert Haas wrote:
> Generally, to do this, it would be necessary to do the following
> things (plus anything I'm forgetting):
It occurs to me that almost exactly this same procedure could be used
to make a *temporary* table into a permanent table. You'd have to
a
On Sat, Jan 8, 2011 at 14:05, Joel Jacobson wrote:
> 2011/1/8 Dimitri Fontaine :
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262493a6537700ee305fb3e096
>
> Nice! Has the patch been accepted and will be made available in future
> versions of pg?
Yes. Once thi
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 7, 2011 at 1:29 PM, Stephen Frost wrote:
> > #1. Add a new 'Top-but-removed-on-DISCARD' context and modify the PLs to
> > use that instead of TopMemoryContext and require any other contexts
> > they create to be children of it.
>
2011/1/8 Dimitri Fontaine :
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262493a6537700ee305fb3e096
Nice! Has the patch been accepted and will be made available in future
versions of pg?
Also, why return NULL for pinned objects? They can also be described
usin
On 5 Jan 2011, at 02:12, Zotov wrote:
Why doesn`t work this query?
select table1.field1, func1.field2 from table1 left outer join func1
(table1.field1) on true where func1.field3 in (20, 100);
The approach people usually use is:
SELECT
f1, (fn).field2
FROM
(
SELECT
field1 as
David Fetter writes:
> On Fri, Jan 07, 2011 at 08:15:12PM -0500, Greg Smith wrote:
>> [1] Silly aside: I was thinking today that I should draw a chart of
>> all the common objections to code that show up here, looking like
>> those maps you see when walking into a mall. Then we can give a
>> cop
Tom Lane
> Now that GIN can index null items, its amindexnulls flag in pg_am really
> ought to be set true. However, looking at the usage of that column,
> I wonder whether we shouldn't just delete it instead. The only present
> usage is a rather convoluted test in CLUSTER to see if the index i
Robert Haas writes:
> I guess the point is that if this gets committed as a core function
> written in C, we don't need any other implementations. But I don't
> recall ever seeing a commit for that one go by...
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6cc2deb86e9183262
On Fri, Jan 7, 2011 at 1:29 PM, Stephen Frost wrote:
> #1. Add a new 'Top-but-removed-on-DISCARD' context and modify the PLs to
> use that instead of TopMemoryContext and require any other contexts
> they create to be children of it.
I'm guessing that just resetting the memory context i
On Fri, Jan 7, 2011 at 8:34 AM, Zotov wrote:
> Thank you for your answer. Sorry, what i don`t find it myself.
> But I can`t see when it will be done? If nobody can do this (maybe no time)
> what i can do to help?! I know C - Language only to read code. (I`m
> Delphi-programmer) and this is not tha
On Sat, Jan 8, 2011 at 1:59 AM, Joel Jacobson wrote:
> 2011/1/7 Jim Nasby :
>> BTW, if you're looking at making pg_depnd easier to use, see
>> http://archives.postgresql.org/message-id/129774-sup-2...@alvh.no-ip.org
>
> I guess there are more than one ways to do it, C, sql, plperl, plpgsql. :
On Fri, Jan 7, 2011 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane wrote:
>>> Between
>>> amclusterable, amsearchnulls, and amoptionalkey, I believe that we have
>>> quite enough flags already to cover what anything else actually
>>> needs-to-know
44 matches
Mail list logo
