2011/1/19 Stephen Frost :
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think we should reject this one.
>
> Works for me.
>
>> Using a switch there is a bit problematic since in some cases you want
>> to use "break" to exit the loop. We could replace such breaks by gotos,
>> but that would be ano
On 20.01.2011 03:05, Kevin Grittner wrote:
If we don't do something like this, do we just provide REPEATABLE
READ on the standby as the strictest level of transaction isolation?
If so, do we generate an error on a request for SERIALIZABLE, warn
and provide degraded behavior, or just quietly give
On Thu, Jan 20, 2011 at 12:16, Stephen Frost wrote:
> This patch looked good, in general, to me. I added a few documentation
> updates and a comment, but it's a very straight-forward patch as far as
> I can tell. Passes all regressions and my additional testing.
Looks good and useful for me, to
On Wed, Jan 19, 2011 at 12:12:39AM -0500, Joachim Wieland wrote:
> Noah, thank you for this excellent review. I have taken over most
> (allmost all) of your suggestions (except for the documentation which
> is still missing). Please check the updated & attached patch for
> details.
Great. I do ge
>
>I seem to recall some muttering about teaching genbki to extract such
comments from the SGML sources or perhaps the C header files. I tend to
agree though that it would be a lot >more work than it's worth. And as you
say, pg_description entries aren't free.
>
I know I can't do all of the wor
On Wed, Jan 19, 2011 at 11:50:12PM -0500, Robert Haas wrote:
> On Wed, Jan 12, 2011 at 8:56 AM, Robert Haas wrote:
> > On Wed, Jan 12, 2011 at 8:14 AM, Noah Misch wrote:
> >> Something like the attached?
> >
> > I haven't really analyzed in this detail, but yes, approximately
> > something sorta
(2011/01/20 13:01), Robert Haas wrote:
> 2011/1/19 KaiGai Kohei:
>>> And how about adding a
>>> ProcessUtility_hook to trap evil non-DML statements that some
>>> nefarious user might issues?
>>>
>> It seems to me reasonable as long as the number of controlled command
>> are limited. For example,
On Wed, Jan 19, 2011 at 11:19 PM, Josh Kupershmidt wrote:
> On Wed, Jan 19, 2011 at 9:09 PM, Robert Haas wrote:
>> This patch doesn't seem terribly consistent to me - we show the name
>> of the call handler and the name of the validator, but for the inline
>> handler we just indicate whether ther
On Wed, Jan 12, 2011 at 8:56 AM, Robert Haas wrote:
> On Wed, Jan 12, 2011 at 8:14 AM, Noah Misch wrote:
>> Something like the attached?
>
> I haven't really analyzed in this detail, but yes, approximately
> something sorta like that.
I looked this over some more tonight. The name "tuples_chang
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
> If we don't do something like this, do we just provide REPEATABLE
> READ on the standby as the strictest level of transaction isolation?
> If so, do we generate an error on a request for SERIALIZABLE, warn
> and provide degraded behavior, o
On Wed, Jan 19, 2011 at 9:37 PM, Magnus Hagander wrote:
>> Great. Thanks for the quick update!
>>
>> Here are another comments:
Here are comments against the documents. The other code looks good.
It's helpful to document what to set to allow pg_basebackup connection.
That is not only the REPLIC
On Wed, Jan 19, 2011 at 9:09 PM, Robert Haas wrote:
> This patch doesn't seem terribly consistent to me - we show the name
> of the call handler and the name of the validator, but for the inline
> handler we just indicate whether there is one or not. That seems like
> something that we should mak
On Wed, Jan 19, 2011 at 6:35 PM, Florian Pflug wrote:
> On Jan20, 2011, at 02:41 , Nathan Boley wrote:
If you think about it, it's a bit ridiculous to look at the whole table
*just* to "estimate" ndistinct - if we go that far why dont we just
store the full distribution and be done
Magnus,
* Stephen Frost (sfr...@snowman.net) wrote:
> mkay, I'm not going to try to make this ready for committer, but will
> provide my comments on it overall. Bit difficult to review when someone
> else is reviewing the base patch too. :/
I went ahead and marked it as 'waiting on author', sinc
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> For now, you need to set wal_keep_segments to make it work properly,
> but if you do the idea is that the tar file/stream generated in the
> base backup will include all the required WAL files.
Is there some reason to not ERROR outright
On Wed, Jan 19, 2011 at 10:16 PM, Stephen Frost wrote:
> This patch looked good, in general, to me. I added a few documentation
> updates and a comment, but it's a very straight-forward patch as far as
> I can tell. Passes all regressions and my additional testing.
I have not looked at the code
2011/1/19 KaiGai Kohei :
>> And how about adding a
>> ProcessUtility_hook to trap evil non-DML statements that some
>> nefarious user might issues?
>>
> It seems to me reasonable as long as the number of controlled command
> are limited. For example, LOAD command may be a candidate being
> control
(2011/01/20 12:10), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> How about feasibility to merge this 4KL chunks during the rest of
>> 45 days? I think we should decide this general direction at first.
>
> I read through this code tonight and it looks pretty straightforward.
> I don't see much re
Greetings,
On 2010-01-15 11:37 PM +200, Marko Tiikkaja wrote:
> On 2010-11-18 5:45 PM +0200, 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.
>
> Rebased against master.
This patch looked good, in general, to
On Wed, Jan 19, 2011 at 9:44 PM, Simon Riggs wrote:
> Noah's patch is trivial, as are the changes to make mine work fully.
I dispute that. In particular:
+ /*
+* Exchange table contents
+*
+* Swap heaps, toast tables, toast indexes
+* all forks
+* a
2011/1/5 KaiGai Kohei :
> How about feasibility to merge this 4KL chunks during the rest of
> 45 days? I think we should decide this general direction at first.
I read through this code tonight and it looks pretty straightforward.
I don't see much reason not to accept this more or less as-is. I'm
Simon Riggs wrote:
> I gave you a quick response to let you know that HS need not be a
> blocker, for this release. If you are saying you have knowingly
> ignored a requirement for a whole year, then I am shocked. How
> exactly did you think this would ever be committed?
I was asked not to dis
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I gave you a quick response to let you know that HS need not be a
> blocker, for this release. If you are saying you have knowingly ignored
> a requirement for a whole year, then I am shocked. How exactly did you
> think this would ever be committed?
Robert Haas wrote:
> Kevin Grittner wrote:
>> I agree it's pretty late in the cycle, but I'm going through all
>> the loose ends and found this one -- which has been hanging out on
>> the Wiki page as an R&D item for over a full year without
>> discussion. :-( If we provide the snapshots (which
On Wed, 2011-01-19 at 19:34 -0600, Kevin Grittner wrote:
> I agree it's pretty late in the cycle, but I'm going through all the
> loose ends and found this one -- which has been hanging out on the
> Wiki page as an R&D item for over a full year without discussion.
> :-( If we provide the snapsh
I think that a major goal of the DocBook format is that it separates
content from presentation, so whatever tool is used to render that
content as HTML for .org isn't necessarily publicly available.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Wed, 2011-01-19 at 21:01 -0500, Robert Haas wrote:
> On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch wrote:
> > I think Simon was referring to the proof-of-concept sketch I had included
> > with
> > my review.
>
> I think it's a bit late to be turning proofs-of-concept into code at
> this point,
On Wed, Jan 19, 2011 at 9:35 PM, Florian Pflug wrote:
> Also, in my personal experience this isn't really the area we've got
> problems now. The problem cases for me always were queries with a rather
> large number of joins (7 to 10 or so) plus rather complex search
> conditions. The join order, n
On Wed, Jan 19, 2011 at 5:13 PM, Tomas Vondra wrote:
>>> Regarding the crash scenario - if the commit fails, just throw away the
>>> local estimator copy, it's not needed. I'm not sure how to take care of
>>> the case when commit succeeds and the write of the merged estimator
>>> fails, but I thin
On Jan20, 2011, at 02:41 , Nathan Boley wrote:
>>> If you think about it, it's a bit ridiculous to look at the whole table
>>> *just* to "estimate" ndistinct - if we go that far why dont we just
>>> store the full distribution and be done with it?
>>
>> - the best you could do is to average the
>>
On Wed, Jan 19, 2011 at 9:13 PM, Stephen Frost wrote:
> Greetings,
>
> * Peter Geoghegan (peter.geoghega...@gmail.com) wrote:
>> I do this all the time. Anyway, I intend for this doc patch to be
>> backported to 8.4 as a bugfix, which is part of the reason why it
>> isn't invasive - it's just a cl
On 20/01/11 01:26, Jan Urbański wrote:
> On 19/01/11 10:57, Jan Urbański wrote:
>> On 18/01/11 23:22, Peter Eisentraut wrote:
>>> #2: It looks like this loses some information/formatting in the error
>>> message. Should we keep the pointing arrow there?
>
>>> CONTEXT: PL/Python function "sql_sy
Greetings,
* Peter Geoghegan (peter.geoghega...@gmail.com) wrote:
> I do this all the time. Anyway, I intend for this doc patch to be
> backported to 8.4 as a bugfix, which is part of the reason why it
> isn't invasive - it's just a clarification. Clearly if it makes sense
> for 9.1, it makes just
On Wed, Jan 19, 2011 at 1:53 PM, Bruce Momjian wrote:
> Is there a reason we only use O_DIRECT with open_* sync options?
> xlogdefs.h says:
>
> /*
> * Because O_DIRECT bypasses the kernel buffers, and because we never
> * read those buffers except during crash recovery, it is a win to use
> *
On Wed, Jan 19, 2011 at 5:47 PM, Andreas Karlsson wrote:
> The patch looks alright now so I will mark it as ready for committer
> now.
This patch doesn't seem terribly consistent to me - we show the name
of the call handler and the name of the validator, but for the inline
handler we just indicat
On Thu, Jan 20, 2011 at 10:53 AM, Tom Lane wrote:
>> I'm not sure why that's the right solution. Why do you think that we should
>> not create the tablespace under the $PGDATA directory? I'm not surprised
>> that people mounts the filesystem on $PGDATA/mnt and creates the
>> tablespace on it.
>
>
>
> Not true. You're missing the goal of this effort - to get ndistinct
> estimate for combination of multiple columns. Which is usually
> pathological in case of dependent columns.
> Again, don't think about a single column (although even in that case
> there are known fail cases). Think about
Kevin's suggestion seems eminently reasonable to me and probably the
best approach one can do for SSI and hot standby. Pulling it off in
time for 9.1 would be a stretch; 9.2 seems quite doable.
It's worth noting that one way or another, the semantics of
SERIALIZABLE transactions on hot standby rep
On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch wrote:
> I think Simon was referring to the proof-of-concept sketch I had included with
> my review.
I think it's a bit late to be turning proofs-of-concept into code at
this point, no matter who came up with them.
--
Robert Haas
EnterpriseDB: http://
On Wed, Jan 19, 2011 at 8:34 PM, Kevin Grittner
wrote:
> I agree it's pretty late in the cycle, but I'm going through all the
> loose ends and found this one -- which has been hanging out on the
> Wiki page as an R&D item for over a full year without discussion.
> :-( If we provide the snapshots
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 19, 2011 at 6:04 PM, Stephen Frost wrote:
> > I'm going to mark this returned to author with feedback.
>
> That implies you don't think it should be considered further for this
> CommitFest. Perhaps you mean Waiting on Author?
I did, ac
On Wed, Jan 19, 2011 at 08:55:22PM -0500, Robert Haas wrote:
> On Wed, Jan 19, 2011 at 7:57 PM, Simon Riggs wrote:
> > On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
> >
> >> I'll go ahead and mark the patch Returned with Feedback.
> >
> > My understanding of the meaning of that is polite re
On Wed, Jan 19, 2011 at 6:04 PM, Stephen Frost wrote:
> I'm going to mark this returned to author with feedback.
That implies you don't think it should be considered further for this
CommitFest. Perhaps you mean Waiting on Author?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
On Wed, Jan 19, 2011 at 7:57 PM, Simon Riggs wrote:
> On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
>
>> I'll go ahead and mark the patch Returned with Feedback.
>
> My understanding of the meaning of that is polite rejection. If you do
> that there is no further author comment and we move
Fujii Masao writes:
> On Thu, Jan 20, 2011 at 2:21 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> What I'm worried about is the case where a tablespace is created
>>> under the $PGDATA directory.
>> What would be the sense of that? If you're concerned about whether the
>> code handles it corre
On Thu, Jan 20, 2011 at 12:57:23AM +, Simon Riggs wrote:
> On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
>
> > I'll go ahead and mark the patch Returned with Feedback.
>
> My understanding of the meaning of that is polite rejection. If you do
> that there is no further author comment a
On Thu, Jan 20, 2011 at 2:21 AM, Tom Lane wrote:
> Fujii Masao writes:
>> What I'm worried about is the case where a tablespace is created
>> under the $PGDATA directory.
>
> What would be the sense of that? If you're concerned about whether the
> code handles it correctly, maybe the right solut
>> If you think about it, it's a bit ridiculous to look at the whole table
>> *just* to "estimate" ndistinct - if we go that far why dont we just
>> store the full distribution and be done with it?
>
> - the best you could do is to average the
> individual probabilities which gives ... well, 1/ndis
Simon Riggs wrote:
> In this release? Maybe? In later releases? Yes.
>
> If it blocks your excellent contribution in this release, then
> from me, "no". If you can achieve this in this release, yes.
> However, if this is difficult or complex, then I would rather say
> "not yet" quickly now, tha
On Wed, Jan 19, 2011 at 9:37 PM, Magnus Hagander wrote:
>> The "fast or slow" seems to lead users to always choose "fast". Instead,
>> what about "fast or smooth", "fast or spread" or "immediate or delayed"?
>
> Hmm. "fast or spread" seems reasonable to me. And I want to use "fast"
> for the fast
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
> Here's an issue for feedback from the community -- do we want to
> support truly serializable transactions on hot standby machines?
In this release? Maybe? In later releases? Yes.
If it blocks your excellent contribution in this release,
Here's an issue for feedback from the community -- do we want to
support truly serializable transactions on hot standby machines?
The best way Dan and I have been able to think to do this is to
build on the SERIALIZABLE READ ONLY DEFERRABLE behavior. We are
able to obtain a snapshot and then che
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
> I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is polite rejection. If you do
that there is no further author comment and we move to July 2011. That
then also rejects your own patch with what
On 19/01/11 10:57, Jan Urbański wrote:
> On 18/01/11 23:22, Peter Eisentraut wrote:
>> #2: It looks like this loses some information/formatting in the error
>> message. Should we keep the pointing arrow there?
>> CONTEXT: PL/Python function "sql_syntax_error"
>> -ERROR: syntax error at or near
On Jan19, 2011, at 23:44 , Nathan Boley wrote:
> If you think about it, it's a bit ridiculous to look at the whole table
> *just* to "estimate" ndistinct - if we go that far why dont we just
> store the full distribution and be done with it?
The crucial point that you're missing here is that ndist
Dne 19.1.2011 23:44, Nathan Boley napsal(a):
> 1) The distribution of values in a table is rarely pathological, and
> usually follows one of several common patterns. ( IOW, we have good
> heuristics )
Not true. You're missing the goal of this effort - to get ndistinct
estimate for combination of m
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> attached patch contains a implementation of iteration over a array:
I've gone through this patch and, in general, it looks pretty reasonable
to me. There's a number of places where I think additional comments
would be good and maybe s
On Tue, 2011-01-18 at 19:34 -0500, Josh Kupershmidt wrote:
> Got that now too. I lost my ~/.emacs file recently, which is mostly
> why I'm making whitespace mistakes. Rebuilding slowly though;
> (setq-default show-trailing-whitespace t) is what I needed.
Aha, I see.
> I left the "Call Handler" an
Hi Simon,
I'm reviewing this patch for CommitFest 2011-01.
On Sat, Jan 15, 2011 at 10:02:03PM +, Simon Riggs wrote:
> On Tue, 2010-12-14 at 19:48 +, Simon Riggs wrote:
> > REPLACE TABLE ying WITH yang
> Patch. Needs work.
First, I'd like to note that the thread for this patch had *four*
On Wed, Jan 19, 2011 at 2:13 PM, Tomas Vondra wrote:
> Dne 19.1.2011 20:25, Robert Haas napsal(a):
>> On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra wrote:
>>> Yes, I was aware of this problem (amount of memory consumed with lots of
>>> updates), and I kind of hoped someone will come up with a rea
Robert Haas writes:
> On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
>> Well, on my machine pg_description is about 210K (per database) as of
>> HEAD. 90% of its contents are pg_proc entries, though I have no good
>> fix on how much of that is for internal-use-only functions. A very
>> rough
Dne 19.1.2011 20:46, Tom Lane napsal(a):
> Robert Haas writes:
>> ... I guess I'm just saying I'd think really, really hard
>> before abandoning the idea of periodic sampling. You have to get an
>> awful lot of benefit out of those cross-column stats to make it worth
>> paying a run-time cost for
Dne 19.1.2011 20:25, Robert Haas napsal(a):
> On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra wrote:
>> Yes, I was aware of this problem (amount of memory consumed with lots of
>> updates), and I kind of hoped someone will come up with a reasonable
>> solution.
>
> As far as I can see, periodically
On Wed, Jan 19, 2011 at 2:59 PM, Peter Eisentraut wrote:
> On ons, 2011-01-19 at 00:52 -0300, Alvaro Herrera wrote:
>> Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
>>
>> > #16: This is probably pointless because pgindent will reformat this.
>>
>> pgindent used to rem
On Wed, Jan 19, 2011 at 4:18 PM, Tom Lane wrote:
> One idea that I think we discussed was to tie cache entries to the
> memory context they were demanded in, and mark them unused at the next
> context reset/delete. That way they'd be considered unused at the same
> points where the current implem
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If we could solve the refcounting problem I think this would be a
>> very significant win.
> Instead of trying to keep a refcount, how about just evicting from
> the buffer as needed based on LRU?
Well, unless you know for certain that an item is n
On 19 January 2011 21:10, Tom Lane wrote:
> Thom Brown writes:
>> I've attached a couple minor fixes to the docs. One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> Applied, thanks.
Cheers Mr Lane.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Regis
Thom Brown writes:
> I've attached a couple minor fixes to the docs. One relating to
> SECURITY LABEL and the other for pg_class.relpersistence
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Tom Lane wrote:
> If we could solve the refcounting problem I think this would be a
> very significant win.
Instead of trying to keep a refcount, how about just evicting from
the buffer as needed based on LRU?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Robert Haas writes:
> I do remember that discussion. Aside from the problem you mention, it
> also seems that maintaining the hash table and doing lookups into it
> would have some intrinsic cost.
Well, sure, but it's still far cheaper than going out to the toast table
(which will require multip
Dimitri Fontaine writes:
> For the GIN indexes, we have 2 methods for building the index and 3
> others to search it to solve the query. You're proposing that the 2
> former methods would be in the opfamily and the 3 later in the opclass.
Actually the other way around. An opclass is the subset
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think we should reject this one.
Works for me.
> Using a switch there is a bit problematic since in some cases you want
> to use "break" to exit the loop. We could replace such breaks by gotos,
> but that would be another strike against the argument tha
Stephen Frost writes:
> While I can certainly appreciate wanting to remove redundant code, I
> don't think this change actually improves the situation. The problem is
> more than just that we might want to make a change to 'while' but not
> 'for', it's also that it makes it very difficult to foll
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>>> Which brings up another point though. I have a personal TODO item to
>>> make the comments for operator support functions more consistent:
>>> http://archives.postgresql
On Wed, Jan 19, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane wrote:
>>> Robert Haas writes:
Yeah. Many-times-repeated detoasting is really bad, and this is not
the only place in the backend where we have this problem. :-(
>
>>>
Robert Haas writes:
> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>> Which brings up another point though. I have a personal TODO item to
>> make the comments for operator support functions more consistent:
>> http://archives.postgresql.org/message-id/21407.1287157...@sss.pgh.pa.us
>> Should
Tom Lane writes:
> I think you missed the point: right now, to use both the core and
> intarray operators on an integer[] column, you have to create *two*
> GIN indexes, which will have exactly identical contents. I'm looking
> for a way to let intarray extend the core opfamily definition so that
On ons, 2011-01-19 at 00:52 -0300, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
>
> > #16: This is probably pointless because pgindent will reformat this.
>
> pgindent used to remove useless braces around single-statement blocks,
> but this b
Robert Haas writes:
> On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Yeah. Many-times-repeated detoasting is really bad, and this is not
>>> the only place in the backend where we have this problem. :-(
>> Yeah, there's been some discussion of a more general solu
Robert Haas writes:
> ... I guess I'm just saying I'd think really, really hard
> before abandoning the idea of periodic sampling. You have to get an
> awful lot of benefit out of those cross-column stats to make it worth
> paying a run-time cost for them.
I've been trying to not discourage Toma
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
>> wrote:
>>> Pages like this one have column comments for the system tables:
>>>
>>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
>
>> Oh, I see. I don't think we
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> This patch remove redundant rows from PL/pgSQL executor (-89 lines).
While I can certainly appreciate wanting to remove redundant code, I
don't think this change actually improves the situation. The problem is
more than just that we m
Excerpts from Robert Haas's message of mié ene 19 15:25:00 -0300 2011:
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for keeping the two places in sync.
Maybe autogenerate both the .sgml and the postgres.description files
from a single source.
> And there'd be
Robert Haas writes:
> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
> wrote:
>> Pages like this one have column comments for the system tables:
>>
>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for ke
On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra wrote:
> Yes, I was aware of this problem (amount of memory consumed with lots of
> updates), and I kind of hoped someone will come up with a reasonable
> solution.
As far as I can see, periodically sampling some or all of the table is
really the only
Robert Haas writes:
> On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane wrote:
>> AFAICS that means integrating contrib/intarray into core. Independently
>> of whether that's a good idea or not, PG is supposed to be an extensible
>> system, so it would be nice to have a solution that supported add-on
>>
Thom Brown wrote:
> relkind in the same table is the same type, but isn't displayed as
> "char" in the docs, and the same applies to many other system
tables.
> They would need changing too then.
>
> Examples are:
>
> pg_type.typtype
> pg_proc.provolatile
> pg_attribute.attstorage
That's a g
Is there a reason we only use O_DIRECT with open_* sync options?
xlogdefs.h says:
/*
* Because O_DIRECT bypasses the kernel buffers, and because we never
* read those buffers except during crash recovery, it is a win to use
* it in all cases where we sync on each write(). We could allow O_D
Noah Misch writes:
> On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
>> In the meantime, the proposal at hand seems like a bit of a stop-gap,
>> which is why I'd prefer to see something with a very minimal code
>> footprint. Detoast at assignment would likely need only a few lines
>> of
On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
>>> I think you missed the point: right now, to use both the core and
>>> intarray operators on an integer[] column, you have to create *two*
>>> GIN indexes, which will ha
Robert Haas writes:
> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
>> I think you missed the point: right now, to use both the core and
>> intarray operators on an integer[] column, you have to create *two*
>> GIN indexes, which will have exactly identical contents. I'm looking
>> for a way
On 19 January 2011 18:11, Kevin Grittner wrote:
> Thom Brown wrote:
>
>> I've attached a couple minor fixes to the docs. One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> relpersistence should be "char", not char.
> Oddly enough, there is a difference.
>
> -Kevin
r
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
wrote:
> Pages like this one have column comments for the system tables:
>
> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
Oh, I see. I don't think we want to go there. We'd need some kind of
system for keeping the two places in sync. An
Thom Brown wrote:
> I've attached a couple minor fixes to the docs. One relating to
> SECURITY LABEL and the other for pg_class.relpersistence
relpersistence should be "char", not char.
Oddly enough, there is a difference.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Hi,
I've attached a couple minor fixes to the docs. One relating to
SECURITY LABEL and the other for pg_class.relpersistence
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
doc_fixes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing
On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule
> > wrote:
> >> opinion isn't strong in this topic. One or twenty useless detoasting
> >> isn't really significant in almost use cases (problem is thousands
> >> det
On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Oh, wait a minute: there's a bad restriction there, namely that a
>>> contrib module could only add "loose" operators that had different
>>> declared input types from the ones known to the core o
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule
>> wrote:
>>> opinion isn't strong in this topic. One or twenty useless detoasting
>>> isn't really significant in almost use cases (problem is thousands
>>> detoasting).
>
Dimitri Fontaine writes:
> Tom Lane writes:
>> Oh, wait a minute: there's a bad restriction there, namely that a
>> contrib module could only add "loose" operators that had different
>> declared input types from the ones known to the core opclass.
> I would have though that such contrib would th
On Wed, Jan 19, 2011 at 11:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> ... So what we
>> want to do is write a percentage of them, in a way that guarantees
>> that they'll all eventually get written if people continue to access
>> the same data.
>
> The word "guarantee" seems quite inappropri
1 - 100 of 144 matches
Mail list logo
