On 01/18/2011 06:44 PM, Robert Haas wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure wrote:
a few weeks back I hacked an experimental patch that removed the hint
bit action completely. the results were very premature and/or
incorrect, but my initial findings suggested that hint bits migh
On 01/19/2011 09:03 AM, Andrea Suisani wrote:
On 01/18/2011 06:44 PM, Robert Haas wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure wrote:
a few weeks back I hacked an experimental patch that removed the hint
bit action completely. the results were very premature and/or
incorrect, but my i
On Tue, Jan 18, 2011 at 10:03:01AM +0200, Heikki Linnakangas wrote:
>> That isn't ever going to happen, unless you'd like to give up hash joins
>> and hash aggregation on text values.
>
> You could canonicalize the string first in the hash function. I'm not
> sure if we have all the necessary inf
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. Otherwise
> there'd be a conflict with the contrib module and core needing to i
On 18/01/11 23:22, Peter Eisentraut wrote:
> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>>> Here they are. There are 16 patches in total. They amount to what's
>>> currently in my refactor branch (and almost to what I've sent
On Tue, 2011-01-18 at 10:51 +0200, Heikki Linnakangas wrote:
> On 18.01.2011 07:15, Jim Nasby wrote:
> > Shouldn't the comment read "If first time through"?
> >
> > /*
> > * If not first time through, get workspace to remember main XIDs in. We
> > * malloc it permanently to avoid repe
On 19/01/11 02:06, Hitoshi Harada wrote:
> 2011/1/19 Peter Eisentraut :
>> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
Here they are. There are 16 patches in total. They amount to what's
currently in my refactor bra
On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > Is there *any* usecase for setting them differently though?
>
> I can't believe we're still engaged in painting this bikeshed. Let's
> just control it off log_connections and have done.
Yes, this is a waste of time
Hello
The EXECUTE statement doesn't support a parametrization via
SPI_execute_with_args call and PQexecParams too. It can be a security
issue. If somebody use a prepared statement as protection to sql
injection, then all security goes out, because he has to call EXECUTE
without parametrization.
R
2011/1/19 Jan Urbański :
> On 19/01/11 02:06, Hitoshi Harada wrote:
>> - -1 is used as the initial value of PLyTypeInfo.is_rowtype. Why not 0?
>
> See the comments in struct PLyTypeInfo:
>
> is_rowtype can be: -1 = not known yet (initial state); 0 = scalar
> datatype; 1 = rowtype; 2 = rowtype, but
On 19.01.2011 12:53, Pavel Stehule wrote:
The EXECUTE statement doesn't support a parametrization via
SPI_execute_with_args call and PQexecParams too. It can be a security
issue. If somebody use a prepared statement as protection to sql
injection, then all security goes out, because he has to cal
2011/1/19 Heikki Linnakangas :
> On 19.01.2011 12:53, Pavel Stehule wrote:
>>
>> The EXECUTE statement doesn't support a parametrization via
>> SPI_execute_with_args call and PQexecParams too. It can be a security
>> issue. If somebody use a prepared statement as protection to sql
>> injection, the
On Tue, 2011-01-18 at 19:04 +, Magnus Hagander wrote:
> Log replication connections only when log_connections is on
>
> Previously we'd always log replication connections, with no
> way to turn them off.
You noted that the code was there intentionally, yet you also couldn't
see the reason. Th
On Wed, Jan 19, 2011 at 06:14, Fujii Masao wrote:
> On Wed, Jan 19, 2011 at 4:12 AM, Magnus Hagander wrote:
>> Ah, ok. I've added the errorcode now, PFA. I also fixed an error in
>> the change for result codes I broke in the last patch. github branch
>> updated as usual.
>
> Great. Thanks for the
On Wed, Jan 19, 2011 at 13:36, Simon Riggs wrote:
> On Tue, 2011-01-18 at 19:04 +, Magnus Hagander wrote:
>> Log replication connections only when log_connections is on
>>
>> Previously we'd always log replication connections, with no
>> way to turn them off.
>
> You noted that the code was th
On 19.01.2011 07:45, Joachim Wieland wrote:
On Mon, Jan 17, 2011 at 5:38 PM, Jaime Casanova wrote:
This one is the last version of this patch? if so, commitfest app
should be updated to reflect that
Here are the latest patches all of them also rebased to current HEAD.
Will update the commitfe
On Wed, 2011-01-19 at 13:44 +0100, Magnus Hagander wrote:
> On Wed, Jan 19, 2011 at 13:36, Simon Riggs wrote:
> > On Tue, 2011-01-18 at 19:04 +, Magnus Hagander wrote:
> >> Log replication connections only when log_connections is on
> >>
> >> Previously we'd always log replication connections,
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas wrote:
> On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure wrote:
>> a few weeks back I hacked an experimental patch that removed the hint
>> bit action completely. the results were very premature and/or
>> incorrect, but my initial findings suggested
On Wed, 2011-01-19 at 12:55 +, Simon Riggs wrote:
> How will we diagnose erratic connection problems now?
The point here is that your effort to *remove* pointless log lines now
means that we cannot diagnose production problems with replication
unless we now *add* hundreds of pointless log lin
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure wrote:
> On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas wrote:
>> On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure wrote:
>>> a few weeks back I hacked an experimental patch that removed the hint
>>> bit action completely. the results were very prem
On Wed, Jan 19, 2011 at 7:47 AM, Heikki Linnakangas
wrote:
>> Here are the latest patches all of them also rebased to current HEAD.
>> Will update the commitfest app as well.
>
> What's the idea of storing the file sizes in the toc file? It looks like
> it's not used for anything.
It's part of th
On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs wrote:
> How will we diagnose erratic connection problems now?
As Heikki pointed out, the slave still logs this information, so we
can look there. If that's enough, yeah, you'll have to turn
log_connections on on the master, but I don't think that wil
On 19.01.2011 15:56, Merlin Moncure wrote:
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure wrote:
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure wrote:
a few weeks back I hacked an experimental patch that removed the hint
bit action comp
On Wed, 2011-01-19 at 09:08 -0500, Robert Haas wrote:
> On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs wrote:
> > How will we diagnose erratic connection problems now?
>
> As Heikki pointed out, the slave still logs this information, so we
> can look there. If that's enough, yeah, you'll have to t
On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
> On 19/01/11 02:06, Hitoshi Harada wrote:
> > 2011/1/19 Peter Eisentraut :
> >> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
> >>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> Here they are. There are 16 p
On Jan19, 2011, at 16:16 , Simon Riggs wrote:
> On Wed, 2011-01-19 at 09:08 -0500, Robert Haas wrote:
>> On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs wrote:
>>> How will we diagnose erratic connection problems now?
>>
>> As Heikki pointed out, the slave still logs this information, so we
>> can l
On Wed, Jan 19, 2011 at 8:56 AM, Merlin Moncure wrote:
> Ah, I tested your patch vs stock postgres vs my patch, basically your
> results are unhappily correct (mine was just a hair faster than yours
> which you'd expect). The differential was even wider on my laptop
> class hardware, maybe 26%.
Simon Riggs writes:
> So now we have to check *all* of the standby logs in order to check that
> replication on the master is working without problems. There will be no
> default capability to tie up events on the master with failures of
> replication. Events occurring on multiple standbys will no
On Wed, 2011-01-19 at 16:42 +0100, Florian Pflug wrote:
>
> Could you explain the failure condition you do have in mind where
> logging replication connections unconditionally is beneficial?
Sure.
Replication drops and immediately reconnects during night.
When did that happen? How many times d
On 19/01/11 16:35, David Fetter wrote:
> On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
>> On 19/01/11 02:06, Hitoshi Harada wrote:
>>> - PLy_(input|output)_tuple_funcs() in PLy_trigger_handler() is added.
>>> The comment says it should check for the possibility that the
>>> relation
On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas wrote:
> Here's a new version of the patch based on some experimentation with
> ideas I posted yesterday. At least on my Mac laptop, this is pretty
> effective at blunting the response time spike for the first table
> scan, and it converges to steady-
On Wed, Jan 19, 2011 at 11:05 AM, Simon Riggs wrote:
> The question we should have asked is "Why is removing those log entries
> helpful?". I shouldn't have to justify putting something back, when the
> good reason for its existence was previously explained and there was no
> consensus to remove i
> Robert
>
> I think the first
> thing to do would be to try to come up with a reproducible test case
> where clustering the tables improves performance.
>
On that note, is there any standard way you guys do benchmarks?
> Bruce
>
>I think CLUSTER is a win when you are looking up multiple
On Wed, Jan 19, 2011 at 9:13 AM, Heikki Linnakangas
wrote:
> On 19.01.2011 15:56, Merlin Moncure wrote:
>>
>> On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure
>> wrote:
>>>
>>> On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas
>>> wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure
On Wed, Jan 19, 2011 at 11:18 AM, Merlin Moncure wrote:
> On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas wrote:
>> Here's a new version of the patch based on some experimentation with
>> ideas I posted yesterday. At least on my Mac laptop, this is pretty
>> effective at blunting the response time
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).
Yeah. Many-times-repeated detoasting is really bad, and this is not
the only place in t
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 inappropriate here, since as far as I
can see this approach provides n
Simon Riggs wrote:
> On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
> > Magnus Hagander writes:
> > > Is there *any* usecase for setting them differently though?
> >
> > I can't believe we're still engaged in painting this bikeshed. Let's
> > just control it off log_connections and have done
2011/1/19 Robert Haas :
> 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).
>
> Yeah. Many-times-repeated detoasting is really bad,
Bruce Momjian writes:
> Simon Riggs wrote:
>> I'm particularly concerned that people make such changes too quickly.
>> There are many things in this area of code that need changing, but also
>> many more that do not. If we are to move forwards we need to avoid going
>> one step forwards, one step
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).
> Yeah. Many-times-repeated detoasting is really bad, and
Tom Lane wrote:
> Bruce Momjian writes:
> > Simon Riggs wrote:
> >> I'm particularly concerned that people make such changes too quickly.
> >> There are many things in this area of code that need changing, but also
> >> many more that do not. If we are to move forwards we need to avoid going
> >>
Alvaro Herrera writes:
> 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 behavior was removed years ago because i
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 solution is to add code to
CREATE TABLESPACE to disallow it.
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
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 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).
>
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: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
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
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
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
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
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 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
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
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
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
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
>>
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 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
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
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
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
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
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
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
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
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
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. :-(
>
>>>
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
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
* 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
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
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
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
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
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
"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 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
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
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
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
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
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
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 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
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
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
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
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 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
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 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,
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
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
>> 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
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
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
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
1 - 100 of 144 matches
Mail list logo
