On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ryan Bradetich rbradet...@gmail.com writes:
This is one of the things I wanted to start looking at for 8.5.
My idea was to optionally use : or @ (not sure which is more popular) to
specify this token is only a variable
Hello Robert,
I have been bitten by this problem many times as well.
I wonder whether it would be possible to make PL/pgsql take :foo to
mean the parameter named foo, and then provide an option to make that
THE ONLY WAY to refer to the parameter foo. For
backward-compatibility, and
to TODO:
Reduce data row alignment requirements on some 64-bit systems
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php
---
Ryan Bradetich wrote:
Hello all,
Here is a proof
Hello Zdenek,
On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Just a quick look. At first point. Your change introduces new page layout
version. Which is not acceptable from my point of view for 8.4 (it add
I would like to see this patch (or some variant) go in if
Hello Zdenek,
On Thu, Oct 9, 2008 at 12:38 AM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Ryan Bradetich napsal(a):
On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala [EMAIL PROTECTED]
wrote:
I would like to see this patch (or some variant) go in if possible.
Since the inplace
upgrades a concern
Hello ITAGAKI-san,
I apologize for not replying earlier, I needed to head out to work.
On Thu, Oct 9, 2008 at 5:01 AM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] wrote:
Here is a proof-of-concept patch for reducing the alignment
requirement for heap tuples
Hello all,
Here is a proof-of-concept patch for reducing the alignment
requirement for heap tuples on 64-bit systems.
This patch passes the regression tests and a couple of other data sets
I have thrown at it.
I am hoping to get some early feedback on this patch so I have time to
make any
Hello Robert,
On Fri, Sep 5, 2008 at 8:13 PM, Robert Haas [EMAIL PROTECTED] wrote:
Updated patch attached, based on comments from Ryan Bradetich and Tom
Lane, and sync'd to latest CVS version.
Thanks for the update. I am out of town until tomorrow evening.
I will re-review this patch when I
Hello all,
Here is my review of the Test citext casts written by David Wheeler:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
1. The patch applies cleanly to the latest GIT repository.
2. The citext type installs, uninstalls, and re-installs cleanly.
3. The coding style is
Hello all,
On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
After a cursory glance at the HeapTupleHeaderData structure, it appears it
could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
worried about
Hello Simon,
On Mon, Sep 1, 2008 at 9:35 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-08-28 at 19:57 -0700, Ryan Bradetich wrote:
I just wanted to throw out another possible use for this GUC. There
maybe a better way to
solve this problem, but I believe this patch would be useful
Hello Martijn,
You need to arrange testing on an architechture that has strict
alignment reuiqrements. For example i386 doesn't care about alignment
at all and will anything from anywhere, with performance degradation.
Other architechtures will simply throw exceptions, that's the smoke
Hello Tom,
On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
The patch concept is fairly simple.
1. Add a new boolean local variable: require_max_align
(initialized to false).
This really can't possibly work, because you'd need
Hello Greg,
On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
4. If require_max_align = true, use the MAXALIGN macro; otherwise
use the INTALIGN macro.
Huh, I didn't think of doing it like that.
But I'm confused. You seem
Hello Greg,
On Tue, Sep 2, 2008 at 9:54 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
The structure on the page is to have a bunch of tuples stored one after the
other. Each tuple is maxaligned after the previous (actually before the
previous since
Hello Tom,
Well, as Greg pointed out, setting t_hoff correctly should be sufficient
for squeezing out useless padding between the tuple header and the tuple
data. The real objection here is that that's leaving most of the
possible gain still on the table. The tuple *as a whole* (header and
Hello all,
Robert Haas submitted the TRUNCATE permissions patch for the September
commit fest:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
I had some extra time tonight, so I downloaded, installed and reviewed this
patch.
Here are my findings:
1. I found the patch style to be
Hello all,
On Sun, Aug 31, 2008 at 11:55 PM, Ryan Bradetich [EMAIL PROTECTED]wrote:
I do not believe this is a huge issue since truncate is prohibited on the
system catalogs
by the truncate_check_rel().
template1=# truncate pg_authid;
ERROR: permission denied: pg_authid is a system
I had intended to send this message to the pgsql-hackers mailing list as
well.
Thanks,
- Ryan
-- Forwarded message --
From: Ryan Bradetich [EMAIL PROTECTED]
Date: Mon, Sep 1, 2008 at 2:20 PM
Subject: Re: [HACKERS] [Patch Review] TRUNCATE Permission
To: Tom Lane [EMAIL PROTECTED
Hello,
Sorry for the new thread on this topic, I did not have a copy in my inbox I
could replay to :(
I am not sure of the status of the patch, but I did read through the thread
at:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00054.php
I just wanted to throw out another possible
On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote:
On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote:
Here is the first pass at the unsigned data type I have been working on.
I am planning on adding these to the September 2008 commitfest wiki page.
The unsigned data type
Hello all,
Here is the first pass at the unsigned data type I have been working on.
I am planning on adding these to the September 2008 commitfest wiki page.
The unsigned data type is not targeted for core, but for the uint PgFoundry
project.
The uint.c.gz file is the main source file for the
Hello all,
I have been digging into the database page layout (specifically the tuples)
to ensure the unsigned integer types were consuming the proper storage.
While digging around, I found one thing surprising:
It appears the heap tuples are padded at the end to the MAXALIGN distance.
Below is
Hello Greg,
On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark [EMAIL PROTECTED]wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
After a cursory glance at the HeapTupleHeaderData structure, it appears
it
could be aligned with INTALIGN instead of MAXALIGN. The one structure I
was
worried
Hello All,
I wanted to pass some performance data on to the group regarding the
unsigned integer
data types I am working on. I tested on two systems running Ubuntu
Hardy. The first system
is an 8 x 2.66GHz x86-64 processor system. The second system is a 2 x
533 celeron i386
system. For this
Tom,
On Tue, Jul 29, 2008 at 2:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, that's the point of the proposal. I think the issue has come up
once or twice before, too, else I'd not be so interested in a general
solution. (digs in archives ... there was some discussion of this
in connection
Hello Tom,
On Wed, Jul 30, 2008 at 7:50 AM, Tom Lane [EMAIL PROTECTED] wrote:
Dunno, I forget what the conclusion was about implicit casting for the
unsigned types in your proposal. Have you experimented with seeing
whether, eg, UNION'ing an unsigned with some signed-integer value
behaves
Hello Peter,
On Fri, Jul 25, 2008 at 5:14 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Friday, 25. July 2008 schrieb Ryan Bradetich:
PgFoundry already has an uint project:
http://pgfoundry.org/projects/uint/
Unfortunately this project seems to have not gone anywhere. Last
Hello Greg,
On Fri, Jul 25, 2008 at 3:57 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
My plans for the example above would be:
1. SELECT 15 + 15 -- Throws overflow error.
2. SELECT 15::uint4 + 15 -- Returns
Hello Dann,
On Fri, Jul 25, 2008 at 1:06 PM, Dann Corbit [EMAIL PROTECTED] wrote:
At the cost of one bit of storage, you have compatible types using
Thanks for your review and feedback! Unfortunately, I do need the full range
of the unsigned types for the project I am looking at. The reason
Tom,
On Fri, Jul 25, 2008 at 12:32 PM, Tom Lane [EMAIL PROTECTED] wrote:
Consider the idea of not having any uint4-specific arithmetic operators,
but instead providing the following:
* assignment casts from int4 and int8 to uint4
(these throw error if out of range, of
Hello hackers,
I know the development community is in the middle of the July 2008
commit-fest, so I apologize if this design proposals are in
appropriate at this time.
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support. The data I am
Hello Tom,
On Thu, Jul 24, 2008 at 10:10 PM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support.
This has been proposed before, and foundered before
,
or read any papers, research, etc that relates to this topic.
- Ryan
P.S. the production database is running 7.2.4 if that makes a
difference.
--
Ryan Bradetich [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands
On Mon, 2003-02-17 at 00:15, Tom Lane wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
On Sun, 2003-02-16 at 23:34, Tom Lane wrote:
It's not real clear to me why you bother enforcing a constraint that the
complete row be unique. Wouldn't a useful constraint be that the first
three columns
, but ownership on other structures like sequences, etc can not
be changed without dropping and recreating as the new owner. Would
there be any interest if I worked on a patch to do this too?
Thanks again for all the hard work and a great database!
- Ryan Bradetich
---(end
36 matches
Mail list logo
