Here's my single biggest tip for newcomers to the Postgres source:
if you don't use ctags, glimpse, or some other tool that can quickly
show you all references to a given identifier, go out and get one.
It's one of the easiest ways to learn about things.
I guess Eclipse is the best tool
On Nov 21, 2010, at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
OK, I've committed this, after a fairly heavy rewrite.
thank you very much
Ah, nuts. I forgot to bump catversion.
...Robert
On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So what DO we need to guard against here?
I think the general problem can be stated as process A changes two or
more values in shared memory in a fairly short span of time, and
On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
Ah, nuts. I see now there's a v7. Never mind...
OK. I looked at the right version, now. Hopefully.
It seems we have no regression tests at all for any of the existing
SET SCHEMA commands. This seems like a good time
Jeff Janes wrote:
And for very large memory
systems, even 1% may be too much to cache (dirty*_ratio can only be
set in integer percent points), so recent kernels introduced
dirty*_bytes parameters. I like these better because they do what
they say. With the dirty*_ratio, I could never figure
On Nov 20, 2010, at 9:31 PM, Terry Laurenzo wrote:
Assuming that the JSON datatype (at a minimum) normalizes text for storage,
then the text storage option accounts for about the most expensive path but
with none of the benefits of an internal binary form (smaller size, ability
to cheaply
On Sun, Nov 21, 2010 at 07:53:57AM -0500, Robert Haas wrote:
On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
Ah, nuts. I see now there's a v7. Never mind...
OK. I looked at the right version, now. Hopefully.
It seems we have no regression tests at all for
On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote:
On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote:
On Tue, Oct 26, 2010 at 11:34 AM, David Fetter da...@fetter.org wrote:
Do we need to 'add' it?
Possibly. My understanding is that it couldn't really replace it.
On Nov 21, 2010, at 1:03 PM, David Fetter da...@fetter.org wrote:
Should this really error out? It's just a NOOP, so perhaps a NOTICE
would be more appropriate.
Perhaps, but the purpose of this patch is to streamline the code, not change
the behavior.
...Robert
--
Sent via pgsql-hackers
Robert Haas robertmh...@gmail.com writes:
So, attached is a proposed patch that just adds CheckSetNamespace()
and makes the existing SET SCHEMA commands use it. Barring
objections, I'll go ahead and commit this part.
Thank you for applying the new function to the existing code paths, that
was
On Sun, Nov 21, 2010 at 12:31 AM, Terry Laurenzo t...@laurenzo.org wrote:
What we see from this is that parsing JSON text and generating a binary
representation is cheap, representing approximately 10% of the base case
time. Conversely, anything that involves generating JSON text is expensive,
On Fri, Nov 19, 2010 at 7:50 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Greg Smith's message of vie nov 19 01:52:34 -0300 2010:
I'd think that if configure takes
longer than it has to because the system is heavily loaded, the amount
compilation time is going to suffer
On Sun, Nov 21, 2010 at 1:07 PM, David Fetter da...@fetter.org wrote:
On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote:
On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote:
On Tue, Oct 26, 2010 at 11:34 AM, David Fetter da...@fetter.org wrote:
Do we need to 'add'
On Sun, Nov 14, 2010 at 2:41 PM, Greg Smith g...@2ndquadrant.com wrote:
Boxuan Zhai wrote:
I have plan to fix the above two bugs together. (in fact, I have already
started coding in merge_v202 edition). My question is how should I make my
update be consistent with yours. Is it possible for
On Sun, Nov 21, 2010 at 03:36:58PM -0500, Robert Haas wrote:
On Sun, Nov 21, 2010 at 1:07 PM, David Fetter da...@fetter.org wrote:
On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote:
On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote:
On Tue, Oct 26, 2010 at 11:34
On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Rajanikant Chirmade rajanikant.chirm...@enterprisedb.com writes:
Every identifier is downcase truncated by function
downcase_truncate_identifier()
before using it.
But since the function downcase_truncate_identifier() is
On 11/21/2010 12:31 AM, Terry Laurenzo wrote:
I copied the 5 sample documents from json.org http://json.org's
example section for these tests. These are loaded into a table with a
varchar column 1000 times each (so the test table has 5000 rows in
it). In all situations, the binary
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IIRC this is intentional. Please consult the archives for previous
discussions.
Why would this be intentional?
Well, it's intentional for lack of any infrastructure that would allow
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
Ah, nuts. I see now there's a v7. Never mind...
OK. I looked at the right version, now. Hopefully.
Yeah, that was the most recent one and I linked it in the commit fest
Hello,
I last time added some features to JDBC driver meking in some way experimental
driver, it could be quite usefull, but if it's possible I would like to ask
for some reviews and tests. Maybe some ideas from this will be handly.
Beacause the chageset is huge, I don't give patch set, but
Robert Haas wrote:
Doing all the writes and then all the fsyncs meets this requirement
trivially, but I'm not so sure that's a good idea. For example, given
files F1 ... Fn with dirty pages needing checkpoint writes, we could
do the following: first, do any pending fsyncs for files not among F1
On Sun, Nov 21, 2010 at 04:54:00PM -0500, Greg Smith wrote:
Ultimately what I want to do here is some sort of smarter write-behind
sync operation, perhaps with a LRU on relations with pending fsync
requests. The idea would be to sync relations that haven't been touched
in a while in
Robert Haas robertmh...@gmail.com writes:
2010/11/12 Teodor Sigaev teo...@sigaev.ru:
My variants informs GiST by SK_ORDER flags and consistentFn looks at
strategy number (strategy numbers are different for different purposes).
Yeah. At ten thousand feet, I think the open design question here
Thanks for that informative article. :) Taught me a few new points about
Eclipse :)
On Sun, Nov 21, 2010 at 2:29 PM, Leonardo Francalanci m_li...@yahoo.itwrote:
Here's my single biggest tip for newcomers to the Postgres source:
if you don't use ctags, glimpse, or some other tool that can
On Sunday 21 November 2010 23:19:30 Martijn van Oosterhout wrote:
For a similar problem we had (kernel buffering too much) we had success
using the fadvise and madvise WONTNEED syscalls to force the data to
exit the cache much sooner than it would otherwise. This was on Linux
and it had the
On 11/20/10 6:11 PM, Jeff Janes wrote:
True, but I think that changing these from their defaults is not
considered to be a dark art reserved for kernel hackers, i.e they are
something that sysadmins are expected to tweak to suite their work
load, just like the shmmax and such.
I disagree.
On Sun, Nov 21, 2010 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IIRC this is intentional. Please consult the archives for previous
discussions.
Why would this be intentional?
On Sun, Nov 21, 2010 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I haven't spent any time on this patch yet (hope to start looking at it
next week). As for your specific question above, I don't have a big
problem with reusing ScanKey this way, but I do agree that using
RestrictInfo for
On 11/21/2010 06:09 PM, Robert Haas wrote:
I think that's fair. It actually doesn't seem like it should be that
hard if we knew that the server encoding were UTF8 - it's just a big
translation table somewhere, no?
No, it's far more complex. See for example
On Sun, Nov 21, 2010 at 6:22 PM, Andrew Dunstan and...@dunslane.net wrote:
On 11/21/2010 06:09 PM, Robert Haas wrote:
I think that's fair. It actually doesn't seem like it should be that
hard if we knew that the server encoding were UTF8 - it's just a big
translation table somewhere, no?
Robert Haas robertmh...@gmail.com writes:
That doesn't seem very hard on its face. The trick is what to do with
that information once you've got it. As far as I can tell, you need
to drill some kind of hole that lets you pass additional details
about the desired sort order to the index AM.
Andrew Dunstan and...@dunslane.net writes:
On 11/21/2010 06:09 PM, Robert Haas wrote:
I think that's fair. It actually doesn't seem like it should be that
hard if we knew that the server encoding were UTF8 - it's just a big
translation table somewhere, no?
No, it's far more complex. See for
On Sun, Nov 21, 2010 at 4:54 PM, Greg Smith g...@2ndquadrant.com wrote:
Let me throw some numbers out [...]
Interesting.
Ultimately what I want to do here is some sort of smarter write-behind sync
operation, perhaps with a LRU on relations with pending fsync requests. The
idea would be to
On Sun, Nov 21, 2010 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/21/2010 06:09 PM, Robert Haas wrote:
I think that's fair. It actually doesn't seem like it should be that
hard if we knew that the server encoding were UTF8 - it's just a big
On Sun, Nov 21, 2010 at 4:05 PM, David Fetter da...@fetter.org wrote:
Could someone please commit this? :)
Eh... was there some reason you didn't add it to the CommitFest app?
I forgot.
A fair excuse. :-)
Because that's what I work from.
It's pretty trivial, but I don't feel
On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote:
On Sun, Nov 21, 2010 at 4:05 PM, David Fetter da...@fetter.org wrote:
Could someone please commit this? :)
Eh... was there some reason you didn't add it to the CommitFest app?
I forgot.
A fair excuse. :-)
Because
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 21, 2010 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
spec compliance aside, we know from bitter experience that we cannot use
a definition that lets the Turkish locale fool with the mapping of i/I.
I suspect that locale-dependent
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
I checked cfparser.v2.patch.
It exports the static parseRecoveryCommandFileLine() in xlog.c
as the global
Hi all,
I'd like to revive Fernando Ike's patch implementing the \dL command
for psql to list available languages, last version here:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php
The original patch produced columns Name, Owner, Procedural
Language, Trusted, Call Handler,
On Sun, Nov 21, 2010 at 7:17 PM, David Fetter da...@fetter.org wrote:
On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote:
On Sun, Nov 21, 2010 at 4:05 PM, David Fetter da...@fetter.org wrote:
Could someone please commit this? :)
Eh... was there some reason you didn't add it to
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
I checked cfparser.v2.patch.
On Sun, Nov 21, 2010 at 08:27:34PM -0500, Robert Haas wrote:
On Sun, Nov 21, 2010 at 7:17 PM, David Fetter da...@fetter.org wrote:
On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote:
On Sun, Nov 21, 2010 at 4:05 PM, David Fetter da...@fetter.org wrote:
Could someone please commit
On Sun, Nov 21, 2010 at 8:18 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I'd like to revive Fernando Ike's patch implementing the \dL command
for psql to list available languages, last version here:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php
Please add this patch to
On Mon, Nov 15, 2010 at 3:09 PM, Greg Smith g...@2ndquadrant.com wrote:
So my task list is:
0) Rebase against the HEAD that just code related to this touched today
1) Assume that log_checkpoints is sufficient control over whether the timing
overhead added is worth collecting, and therefore
On Fri, Nov 19, 2010 at 9:55 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
[ new SQL/MED patch ]
I can't help noticing that this patch adds 8,982 lines and removes
408, making it far larger any other patch I've ever seen on this list.
And what that means is that committing all of this in
On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas robertmh...@gmail.com wrote:
Please add this patch to the currently open CommitFest:
Added to 2011-01.
https://commitfest.postgresql.org/action/commitfest_view/open
And please also help with review of patches from the current CommitFest:
On Sun, Nov 21, 2010 at 9:44 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas robertmh...@gmail.com wrote:
Please add this patch to the currently open CommitFest:
Added to 2011-01.
https://commitfest.postgresql.org/action/commitfest_view/open
And
On Tue, Nov 16, 2010 at 04:42, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
I am checking a patch. I found a problem with initdb
Ah, late night brain farts, it appears. Here is a corrected version.
This version cannot be applied cleanly any
2010/11/12 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/11/12 19:34), KaiGai Kohei wrote:
I revised my patch according to the prior suggestions.
I'm sorry. I revised my patch, but not attached.
Please see this attached one.
I'm satisfied with this approach, although I intend to change
On Mon, Nov 22, 2010 at 11:16, Robert Haas robertmh...@gmail.com wrote:
To have a chance of getting a significant portion
of this into PostgreSQL 9.1, it really needs to be broken up into
INDEPENDENTLY COMMITTABLE SUB-PATCHES.
Did we discuss about syntax-only patch is not acceptable because
it
On Sun, Nov 21, 2010 at 10:14 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Nov 22, 2010 at 11:16, Robert Haas robertmh...@gmail.com wrote:
To have a chance of getting a significant portion
of this into PostgreSQL 9.1, it really needs to be broken up into
INDEPENDENTLY
I have done a bunch of benchmarking. It was not easy to find consistent
numbers, so I picked a job and ran the same thing over and over.
I'm running Slackware 13.1 on a desktop computer.
Linux storm 2.6.35.7-smp #1 SMP Sun Oct 10 21:43:07 CDT 2010 i686 AMD
Athlon(tm) 7850 Dual-Core
On Sat, Nov 20, 2010 at 6:46 AM, Joachim Wieland j...@mcknight.de wrote:
I still have the server, if you want me to debug anything or send a
patch against 9.0.1 that gives more output, just let me know.
Per previous Simon's comment, the following information would be useful.
On Fri, Oct 15, 2010 at 03:40, Radosław Smogura
rsmog...@softperience.eu wrote:
Regarding JDBC in the CF process -- other interfaces are handled
there. I haven't seen one patch this size for JDBC since I've been
involved, let alone two competing patches to implement the same
feature. Small
54 matches
Mail list logo
