Just a reminder that this patch is discussing how to break url, emails etc
into its components.
On Mon, Oct 4, 2010 at 3:54 AM, Tom Lane wrote:
> [ sorry for not responding on this sooner, it's been hectic the last
> couple weeks ]
>
> Sushant Sinha writes:
> >> I looked at this patch a bit.
On Wed, Dec 22, 2010 at 8:04 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > 2010/9/13 Teodor Sigaev :
>> >> [updated patch]
>>
>> > I realize I'm repeating myself, but... this patch needs
>> > documentation. It's not optional.
>>
>> I've applied all of this, and written
On 08/12/10 22:41, Peter Eisentraut wrote:
> On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote:
>> Peter suggested having a mail/patch per feature and the way I intend
>> to do that is instead of having a dozen branches, have one and after
>> I'm done rebase it interactively to produce incremen
Alvaro Herrera wrote:
> Excerpts from Quan Zongliang's message of mar dic 21 18:36:11 -0300 2010:
> > On Mon, 29 Nov 2010 10:29:17 -0300
> > Alvaro Herrera wrote:
> >
>
> > > I think the way this should work is that you call postmaster with a new
> > > switch and it prints out its configuration,
Tom Lane wrote:
> Josh Berkus writes:
> > Making it support O_DIRECT would be possible but more complex; I don't
> > see the point unless we think we're going to have open_sync_with_odirect
> > as a seperate option.
>
> Whether it's complex or not isn't really the issue. The issue is that
> what
Josh Berkus wrote:
> On 12/6/10 6:13 PM, Tom Lane wrote:
> > Josh Berkus writes:
> >> OK, patch coming then. Right now test_fsync aborts when O_DIRECT fails.
> >> What should I have it do instead?
> >
> > Report that it fails, and keep testing the other methods.
>
> Patch attached. Includes a
Tom Lane wrote:
> Robert Haas writes:
> > 2010/9/13 Teodor Sigaev :
> >> [updated patch]
>
> > I realize I'm repeating myself, but... this patch needs
> > documentation. It's not optional.
>
> I've applied all of this, and written documentation for all of it,
> except for the contrib/btree_gis
Hello,
[Tried the general forum, didn't hear from anyone so far, trying this forum
now,
please review, thanks]
We are looking to distribute postgres databases to our customers along with our
application. We are currently evaluating postgres version 8.4.4. The database
can be of size 25 gb (c
On Wed, Dec 22, 2010 at 4:54 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Regarding the contention which Tom expects: the extra load on the CLOG
>> would be 100% reads, no? If it's *all* reads, why would we have any
>> more contention than we have now?
>
> Read involves sharelock which still cau
On Wed, 2010-12-22 at 22:08 +0200, Heikki Linnakangas wrote:
> On 22.12.2010 18:12, Merlin Moncure wrote:
> > On Wed, Dec 22, 2010 at 11:06 AM, Tom Lane wrote:
> >> Merlin Moncure writes:
> >>> well, simon's point that hint bits complicate checksum may nor may not
> >>> be the case, but no hint b
On 23/12/10 10:54, Tom Lane wrote:
Josh Berkus writes:
Regarding the contention which Tom expects: the extra load on the CLOG
would be 100% reads, no? If it's *all* reads, why would we have any
more contention than we have now?
Read involves sharelock which still causes contention. Those buf
Josh Berkus writes: > I might be able to test
on some client workloads. We'll see; currently > I lack the
harness to simulate a high level of client contention. We're
pretty successful in doing that with Tsung, even against large
clusters of plproxy nodes. http://tsung.erlang-projects.org
Josh Berkus writes:
> Regarding the contention which Tom expects: the extra load on the CLOG
> would be 100% reads, no? If it's *all* reads, why would we have any
> more contention than we have now?
Read involves sharelock which still causes contention. Those bufmgr
contention storms we saw bef
> Certainly having a choice about configuring them would be a good
> addition in itself, e.g for data warehousing use the hint bits can be a
> considerable impediment so the *ability* to not have them would be a
> huge advantage.
Would need to be a restart option, no?
Regarding the contention w
> I believe that most of the people talking about and wanting checksums
> so far have been wanting them to verify I/O, not to verify that PG has
> no bugs, that RAM is staying charged correctly, and that no stray bits
> have been flipped, and that nobody else happens to be scribbling over
> our sh
On 23/12/10 05:06, Merlin Moncure wrote:
On Wed, Dec 22, 2010 at 10:59 AM, Tom Lane wrote:
Heikki Linnakangas writes:
My gut feeling is that a reasonable compromise is to set hint bits like
we do today, but don't mark the page as dirty when only hint bits are
set. That way you get the benefit
> right -- see the attached clog_stress.sql above. It creates a script
> that inserts records in blocks of 1, deletes half of them, and
> vacuums. Neither the execution of the script nor a seq scan following
> its execution showed an interesting performance difference (which I am
> arbitrari
Marko Tiikkaja writes:
> On 2010-12-22 8:24 PM, Peter Eisentraut wrote:
>> Is this the patch of record? There are no changes to the documentation
>> included.
> I've kept the documentation as a separate patch, but I haven't touched
> it in a very long time. I will work on the documentation if
On 22.12.2010 18:12, Merlin Moncure wrote:
On Wed, Dec 22, 2010 at 11:06 AM, Tom Lane wrote:
Merlin Moncure writes:
well, simon's point that hint bits complicate checksum may nor may not
be the case, but no hint bits = less i/o = less checksumming (unless
you checksum around the hint bits).
On Wed, Dec 22, 2010 at 11:24, David E. Wheeler wrote:
> On Dec 21, 2010, at 8:19 PM, Alex Hunsaker wrote:
>
>> And here is v3, [ ...]
> Awesome. Would you add it to
> https://commitfest.postgresql.org/action/commitfest_view?id=9 please?
Nah, I was willing to spend a couple of hours playing wit
On Wed, Dec 22, 2010 at 12:54:39PM -0600, Kevin Grittner wrote:
> Marko Tiikkaja wrote:
>
> > I think I've used "DML WITH" in the patch, but I don't like that
> > either. Naming this feature seems to be quite a challenge.
> >
> > I'd prefer something short but easily understandable, but those
Marko Tiikkaja wrote:
> I think I've used "DML WITH" in the patch, but I don't like that
> either. Naming this feature seems to be quite a challenge.
>
> I'd prefer something short but easily understandable, but those
> two might be mutually exclusive.
How about?:
DML CTEs
DML-based CTEs
R
On Wed, Dec 22, 2010 at 10:44 AM, Marko Tiikkaja
wrote:
> I'd prefer something short but easily understandable, but those two might be
> mutually exclusive.
Volatile CTE's doesn't add any more clarity either. Maybe "Round Trip
Reduction" CTE's. :)
--
Regards,
Richard Broersma Jr.
--
Sent via
On 2010-12-22 8:28 PM, Peter Eisentraut wrote:
As a side note, I think the term "writable CTE" is a misnomer. The CTE
is not writable. The CTE is the result of a write operation.
A writable CTE would look like this:
WITH foo AS (SELECT ...) UPDATE foo SET ...
a bit like an updatable view.
A
On 2010-12-22 8:24 PM, Peter Eisentraut wrote:
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the edges
and
needs some more comments, but I'm p
As a side note, I think the term "writable CTE" is a misnomer. The CTE
is not writable. The CTE is the result of a write operation.
A writable CTE would look like this:
WITH foo AS (SELECT ...) UPDATE foo SET ...
a bit like an updatable view.
AFAICT, the current patch doesn't use the term, so
On tis, 2010-12-21 at 13:20 -0800, David Fetter wrote:
> On Tue, Dec 21, 2010 at 11:14:31PM +0200, Peter Eisentraut wrote:
> > On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
> > > On 2010-11-12 8:25 PM +0200, I wrote:
> > > > I'm going to take some time off this weekend to get a patch wit
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
> .. and a wild patch appears.
>
> This is almost exactly the patch from 2010-02 without
> CommandCounterIncrement()s. It's still a bit rough around the edges
> and
> needs some more comments, but I'm posting it here anyway.
Is this the
On Dec 21, 2010, at 8:19 PM, Alex Hunsaker wrote:
> And here is v3, fixes the above and also makes sure to properly
> encode/decode SPI arguments. Tested on a latin1 database with latin1
> columns and utf8 with utf8 columns. Also passes make installcheck (of
> course) and changes one or two thin
On Tue, Dec 21, 2010 at 10:15:41PM -0500, Robert Haas wrote:
> A little benchmarking reveals that on my system (MacOS X 10.6.5) it
> appears that strncmp() is faster for a 4 character string, but
> memcmp() is faster for a 5+ character string.
Good call; I hadn't considered that possibility.
> So
On Wed, Dec 22, 2010 at 04:00:30PM +, Simon Riggs wrote:
> On Wed, 2010-12-22 at 17:42 +0200, Heikki Linnakangas wrote:
> > On 22.12.2010 17:31, Simon Riggs wrote:
> > > On Wed, 2010-12-22 at 17:01 +0200, Heikki Linnakangas wrote:
> > >> There's plenty of stuff in memory that's not covered by a
Merlin Moncure writes:
> I'm going to do lots more testing over the holidays. I'm fishing for
> ideas on good ways to flesh things out more.
Based on the analogy to past bufmgr contention problems, I'd suggest
going back through the archives to look for the test cases associated
with context swa
On Wed, 2010-12-22 at 10:59 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > My gut feeling is that a reasonable compromise is to set hint bits like
> > we do today, but don't mark the page as dirty when only hint bits are
> > set. That way you get the benefit of hint bits for tuples that
On Wed, 2010-12-22 at 07:36 -0800, David Fetter wrote:
> >
> > > > 7. Why does ANALYZE skip foreign tables? Surely its really
> > > > important we know things about a foreign table, otherwise we are
> > > > going to optimize things very badly.
> > >
> > > Quite apart from other reasons, such as p
On Wed, Dec 22, 2010 at 11:12 AM, Merlin Moncure wrote:
> On Wed, Dec 22, 2010 at 11:06 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> well, simon's point that hint bits complicate checksum may nor may not
>>> be the case, but no hint bits = less i/o = less checksumming (unless
>>> you checks
On Wed, Dec 22, 2010 at 11:06 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> well, simon's point that hint bits complicate checksum may nor may not
>> be the case, but no hint bits = less i/o = less checksumming (unless
>> you checksum around the hint bits).
>
> I think you're optimistically ass
On Wed, Dec 22, 2010 at 10:59 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> My gut feeling is that a reasonable compromise is to set hint bits like
>> we do today, but don't mark the page as dirty when only hint bits are
>> set. That way you get the benefit of hint bits for tuples that are
Merlin Moncure writes:
> well, simon's point that hint bits complicate checksum may nor may not
> be the case, but no hint bits = less i/o = less checksumming (unless
> you checksum around the hint bits).
I think you're optimistically assuming the extra clog accesses don't
cost any I/O.
On Wed, Dec 22, 2010 at 10:55 AM, Aidan Van Dyk wrote:
> On Wed, Dec 22, 2010 at 10:52 AM, Simon Riggs wrote:
>
>> I'm sure it will take a little while for everybody to understand why a
>> full CRC implementation is both necessary and now possible. Paradigm
>> shifts of thought do seem like telep
On Wed, 2010-12-22 at 17:42 +0200, Heikki Linnakangas wrote:
> On 22.12.2010 17:31, Simon Riggs wrote:
> > On Wed, 2010-12-22 at 17:01 +0200, Heikki Linnakangas wrote:
> >> There's plenty of stuff in memory that's not covered by an
> >> application-level CRC. That's what ECC RAM is for.
> >
> > htt
Heikki Linnakangas writes:
> My gut feeling is that a reasonable compromise is to set hint bits like
> we do today, but don't mark the page as dirty when only hint bits are
> set. That way you get the benefit of hint bits for tuples that are
> frequently accessed and stay in buffer cache. But y
On Wed, Dec 22, 2010 at 12:54:06PM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of mié dic 22 12:36:10 -0300 2010:
> > On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> > > On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
>
> > > > Quite apart from other
On Wed, Dec 22, 2010 at 10:52 AM, Simon Riggs wrote:
> I'm sure it will take a little while for everybody to understand why a
> full CRC implementation is both necessary and now possible. Paradigm
> shifts of thought do seem like teleports, but they can be beneficial.
But please don't deny the r
Excerpts from David Fetter's message of mié dic 22 12:36:10 -0300 2010:
> On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> > On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
> > > Quite apart from other reasons, such as possible ephemerality of
> > > the data, the difficulty
On Tue, Dec 21, 2010 at 07:33:04PM +, Simon Riggs wrote:
> On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
>
> > Attached are revised version of SQL/MED core functionality patches.
>
> Looks very interesting new feature, well done.
While, "read SQL:2008" is generally not super usefu
On Wed, 2010-12-22 at 10:45 -0500, Tom Lane wrote:
> Aidan Van Dyk writes:
> > With this statement, you just moved the goal posts on the checksumming
> > ideas. In fact, you didn't just move the goal posts, you picked the
> > ball up and teleported it to another stadium.
>
> What he said. I can
Aidan Van Dyk writes:
> With this statement, you just moved the goal posts on the checksumming
> ideas. In fact, you didn't just move the goal posts, you picked the
> ball up and teleported it to another stadium.
What he said. I can't imagine that anyone will be interested in any
case other tha
On 22.12.2010 17:31, Simon Riggs wrote:
On Wed, 2010-12-22 at 17:01 +0200, Heikki Linnakangas wrote:
There's plenty of stuff in memory that's not covered by an
application-level CRC. That's what ECC RAM is for.
http://www.google.com/research/pubs/archive/35162.pdf
Google research shows that e
On 22.12.2010 17:31, Simon Riggs wrote:
On Wed, 2010-12-22 at 17:01 +0200, Heikki Linnakangas wrote:
Do you envision that the CRC is calculated at every update, or only when
a page is written out from the buffer cache?
At every update, so there is a clear assertion that the CRC matches the
blo
On Wed, Dec 22, 2010 at 03:00:16PM +, Simon Riggs wrote:
> On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
>
> > Answering a few of your questions
>
> Many thanks.
>
> > > 7. Why does ANALYZE skip foreign tables? Surely its really
> > > important we know things about a foreign table
On Wed, 2010-12-22 at 17:01 +0200, Heikki Linnakangas wrote:
> On 22.12.2010 16:52, Simon Riggs wrote:
> > On Wed, 2010-12-22 at 16:22 +0200, Heikki Linnakangas wrote:
> >> On 22.12.2010 15:59, Simon Riggs wrote:
> >>> On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
> My gut feeli
On 12/22/2010 10:00 AM, Simon Riggs wrote:
7. Why does ANALYZE skip foreign tables? Surely its really important we
know things about a foreign table, otherwise we are going to optimize
things very badly.
Quite apart from other reasons, such as possible ephemerality of the
data, the difficulty
On Wed, Dec 22, 2010 at 9:52 AM, Simon Riggs wrote:
> So what you suggest works only if we restrict CRC checking to blocks
> incoming to the buffer cache, but leaves us unable to do CRC checks on
> blocks once in the buffer cache. Since many blocks stay in cache almost
> constantly, we're left wi
Tom Lane wrote:
> Actually, if we're going to do this at all, we should do
>
> pid
> datadir
> port
> socketdir
> ... here be dragons ...
>
> so that pg_ctl doesn't have to assume the server is running with a
> default value of unix_socket_dir. Not sure what to put
On 22.12.2010 16:52, Simon Riggs wrote:
On Wed, 2010-12-22 at 16:22 +0200, Heikki Linnakangas wrote:
On 22.12.2010 15:59, Simon Riggs wrote:
On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
My gut feeling is that a reasonable compromise is to set hint bits like
we do today, but don
On Wed, Dec 22, 2010 at 9:52 AM, Simon Riggs wrote:
> I think its important for Postgres to implement this in the same release
> as sync rep.
i.e. never, at the rate sync rep has been progressing for the last few months?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
On Wed, 2010-12-22 at 09:03 -0500, Andrew Dunstan wrote:
> Answering a few of your questions
Many thanks.
> > 7. Why does ANALYZE skip foreign tables? Surely its really important we
> > know things about a foreign table, otherwise we are going to optimize
> > things very badly.
>
> Quite apart
On Wed, 2010-12-22 at 16:22 +0200, Heikki Linnakangas wrote:
> On 22.12.2010 15:59, Simon Riggs wrote:
> > On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
> >> My gut feeling is that a reasonable compromise is to set hint bits like
> >> we do today, but don't mark the page as dirty whe
On 22.12.2010 15:59, Simon Riggs wrote:
On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
My gut feeling is that a reasonable compromise is to set hint bits like
we do today, but don't mark the page as dirty when only hint bits are
set. That way you get the benefit of hint bits for tu
On 12/21/2010 02:33 PM, Simon Riggs wrote:
On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
Attached are revised version of SQL/MED core functionality patches.
Looks very interesting new feature, well done.
Can I ask some questions about how this will work?
No particular order, just
On Wed, 2010-12-22 at 15:30 +0200, Heikki Linnakangas wrote:
> > I would vote to put this into 9.1 as a non-default option at restart,
> > opening the door to other features which hint bits are frustrating.
> > People can then choose between those features and the "power of hint
> > bits". I think
On 22.12.2010 15:21, Simon Riggs wrote:
On Tue, 2010-12-21 at 17:42 -0500, Merlin Moncure wrote:
*) is there community interest in a full patch that fills in the
missing details not implemented here?
You're thinking seems sound to me. We now have all-visible flags, fewer
xids, much better clo
On Mon, Dec 20, 2010 at 16:48, Magnus Hagander wrote:
> On Thu, Dec 16, 2010 at 17:13, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Thu, Dec 16, 2010 at 17:07, Tom Lane wrote:
because if you're trying to link against an older libpq, the link will
fail before you ever get to execu
On Tue, 2010-12-21 at 17:42 -0500, Merlin Moncure wrote:
> *) is there community interest in a full patch that fills in the
> missing details not implemented here?
You're thinking seems sound to me. We now have all-visible flags, fewer
xids, much better clog concurrency. Avoiding hint bits would
Sorry for sounding the false alarm. I was not running the vanilla
postgres and that is why I was seeing that problem. Should have checked
with the vanilla one.
-Sushant
On Tue, 2010-12-21 at 23:03 -0500, Tom Lane wrote:
> Sushant Sinha writes:
> > There is a bug in ts_rank_cd. It does not correc
65 matches
Mail list logo
