On 01/18/2011 06:44 PM, Robert Haas wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncuremmonc...@gmail.com 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 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 Moncuremmonc...@gmail.com wrote:
a few weeks back I hacked an experimental patch that removed the hint
bit action completely. the results were very premature and/or
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
Tom Lane t...@sss.pgh.pa.us 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
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 as the
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 repeated
On 19/01/11 02:06, Hitoshi Harada wrote:
2011/1/19 Peter Eisentraut pete...@gmx.net:
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
On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
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.
2011/1/19 Jan Urbański wulc...@wulczer.org:
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 =
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
2011/1/19 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
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
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. That
On Wed, Jan 19, 2011 at 06:14, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jan 19, 2011 at 4:12 AM, Magnus Hagander mag...@hagander.net 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
On Wed, Jan 19, 2011 at 13:36, Simon Riggs si...@2ndquadrant.com 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
On 19.01.2011 07:45, Joachim Wieland wrote:
On Mon, Jan 17, 2011 at 5:38 PM, Jaime Casanovaja...@2ndquadrant.com 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.
On Wed, 2011-01-19 at 13:44 +0100, Magnus Hagander wrote:
On Wed, Jan 19, 2011 at 13:36, Simon Riggs si...@2ndquadrant.com 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
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure mmonc...@gmail.com 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,
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
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
a few weeks back I hacked an experimental patch that removed the hint
On Wed, Jan 19, 2011 at 7:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs si...@2ndquadrant.com 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
On 19.01.2011 15:56, Merlin Moncure wrote:
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncuremmonc...@gmail.com wrote:
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haasrobertmh...@gmail.com wrote:
On Tue, Jan 18, 2011 at 9:24 AM, Merlin Moncuremmonc...@gmail.com wrote:
a few weeks back I hacked
On Wed, 2011-01-19 at 09:08 -0500, Robert Haas wrote:
On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs si...@2ndquadrant.com 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,
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 pete...@gmx.net:
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
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 si...@2ndquadrant.com wrote:
How will we diagnose erratic connection problems now?
As Heikki pointed out, the slave still logs this information, so
On Wed, Jan 19, 2011 at 8:56 AM, Merlin Moncure mmonc...@gmail.com 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
Simon Riggs si...@2ndquadrant.com 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
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 did
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's tupdesc
On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Jan 19, 2011 at 11:05 AM, Simon Riggs si...@2ndquadrant.com 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
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 rows in
On Wed, Jan 19, 2011 at 9:13 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 19.01.2011 15:56, Merlin Moncure wrote:
On Wed, Jan 19, 2011 at 7:57 AM, Merlin Moncuremmonc...@gmail.com
wrote:
On Tue, Jan 18, 2011 at 12:44 PM, Robert Haasrobertmh...@gmail.com
wrote:
On
On Wed, Jan 19, 2011 at 11:18 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Simon Riggs wrote:
On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
2011/1/19 Robert Haas robertmh...@gmail.com:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
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.
Bruce Momjian br...@momjian.us 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,
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
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.
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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 alvhe...@commandprompt.com 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
Fujii Masao masao.fu...@gmail.com 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
On Wed, Jan 19, 2011 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost
On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use
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
Thom Brown t...@linux.com 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 typechar/type, not typechar/type.
Oddly enough, there is a difference.
-Kevin
--
Sent via pgsql-hackers
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com 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
On 19 January 2011 18:11, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Thom Brown t...@linux.com 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 typechar/type, not typechar/type.
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you missed the point: right now, to use both the core and
intarray operators on an integer[] column, you
Noah Misch n...@leadboat.com 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
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
Thom Brown t...@linux.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra t...@fuzzy.cz 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com 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.
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
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
Pages like this one have column comments for the system tables:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
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
Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Which brings up another point though. I have a personal TODO item to
make the comments for operator support functions more consistent:
On Wed, Jan 19, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. Many-times-repeated detoasting is really bad, and this is not
the
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Which brings up another point though. I have a personal TODO item to
make the comments for operator support
Stephen Frost sfr...@snowman.net 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
* 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 that
Dimitri Fontaine dimi...@2ndquadrant.fr 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
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
Thom Brown t...@linux.com 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
On 19 January 2011 21:10, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 2:59 PM, Peter Eisentraut pete...@gmx.net 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
Dne 19.1.2011 20:25, Robert Haas napsal(a):
On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra t...@fuzzy.cz 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,
Dne 19.1.2011 20:46, Tom Lane napsal(a):
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 19, 2011 at 2:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
Dne 19.1.2011 20:25, Robert Haas napsal(a):
On Tue, Jan 18, 2011 at 5:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
Yes, I was aware of this problem (amount of memory consumed with lots of
updates), and I kind of hoped someone will
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 and
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
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
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 ndistinct
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 syntax
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
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 mag...@hagander.net 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 si...@2ndquadrant.com 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
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/ndistinct.
On Thu, Jan 20, 2011 at 2:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
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 and we
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jan 20, 2011 at 2:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
1 - 100 of 144 matches
Mail list logo
