On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker wrote:
> Im of the opinion if we are going to be meddling with the permission
> checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like most solutions would put us back to exactly what you were
On Thu, Jan 14, 2010 at 14:13, Dann Corbit wrote:
> How can I obtain the source code for pg_bulkload?
This is the wrong list, try
http://lists.pgfoundry.org/pipermail/pgbulkload-general/
That being said it seems to be right in the file list
http://pgfoundry.org/frs/?group_id=1000261
http://p
On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
> I am not very happy with ATPrepSetOptions(). I basically just
> retained the logic from ATPrepSetDistinct(), but it doesn't really
> make sense in this context. The idea that we want to support
> attdistinct for system tables and index columns
On Sat, Jan 16, 2010 at 05:39, Robert Haas wrote:
> First, thanks for the review. Detailed comments/questions below.
>
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> On Sun, Jan 10, 2010 at 12:27, Robert Haas wrote:
>>> I am not very happy with ATPrepSe
On Tue, Jan 19, 2010 at 07:49, Robert Haas wrote:
>That will mean that users can't use ALTER TABLE ... ALTER
> COLUMN ... SET STATISTICS DISTINCT for system tables, but I don't
> think that's much of a loss, and it certainly seems cleaner than
> hoping that any additional attoptions we add in the
On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> ***
>> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
>> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
>> aclitem attacl[1];
&
On Tue, Jan 19, 2010 at 23:02, Alex Hunsaker wrote:
> On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
>> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>>> ! text attoptions[1];
>> Unfortunately this change (which is obviously correct and
On Wed, Jan 20, 2010 at 19:51, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> But yes, lets keep it simple for now.
>
> OK. Updated patch attached. Changes:
>
> - Incorporate your previous review patch.
> - Omit attacl and attoptions
On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
>> Seems to me a comment about the above might be nice. Something like
>> /* Things after here are should always be default null */ in
>> pg_attribute.h ?
>
On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> - Allow (ineffective) use of 'require' in plperl
> If the required module is not already loaded then it dies.
> So "use strict;" now works in plperl.
[ BTW I think this is awesome! ]
Id vote for use warnings; as well.
> - Stored procedure
On Sat, Jan 23, 2010 at 11:30, David E. Wheeler wrote:
> On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
>
>> $name =~ s/::|'/_/g; # avoid package delimiters
>> + $name =~ s/'/\'/g;
>
> Looks to me like ' is already handled in the line above t
On Sat, Jan 23, 2010 at 12:42, David E. Wheeler wrote:
> On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
>
>> Well no, i suppose we could fix that via:
>> $name =~ s/[:|']/_/g;
>>
>> Im betting that was the intent.
>
> Doubtful. In Perl, the pac
$BEGIN $prolog $src }
>>> ];
>>>
>>>
>>
>> Ok. (I don't think that'll clash with any later patches.)
>>
>>
>> So, what now? Should I resend the patch with the two 'ok' changes above
>> included, or can the committer make those very minor changes?
>>
>>
>>
>
> I'll pick these up, if Alex marks it ready for committer.
Done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
>> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
>> I'd vote for use warnings; as well.
>
> I would to, but sadly it's not that simple.
>
>
On Tue, Jan 26, 2010 at 23:14, Tom Lane wrote:
> Andrew Dunstan writes:
>> Tim Bunce wrote:
>>> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
>>> SPI functions are not available when the code is run.
>>>
>>> - Added normal interpreter destruction behaviour
>>> END blocks, if any, are r
On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I wrote:
>> Bruce Momjian writes:
>>> With the release of Postgres 9.0, should we consider changing the
>>> default for 'standard_conforming_strings'?
>
>> I'm inclined to think we're going to have enough problems without that.
> [ still bearing s
On Fri, Jan 29, 2010 at 14:03, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Fri, Jan 29, 2010 at 13:42, Tom Lane wrote:
> I stand by the position that it's way too late in the cycle for
> insufficiently-thought-out proposals for major behavioral changes.
After skimming the
On Mon, Jan 25, 2010 at 12:53, Tim Bunce wrote:
> - Added the 'warnings' pragma to the list of modules to load into Safe.
> So plperl functions can now "use warnings;" - added test for that.
*yay*
> - Added 'use 5.008001;' to plc_perlboot.pl as a run-time check to
> complement the configure-ti
On Sat, Jan 30, 2010 at 07:51, Tim Bunce wrote:
> On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
>> A couple of comments. *note* I have not tested this as a whole yet
>> (due to rejects).
>>
>> in plc_perboot.pl
>> +$funcsrc .= qq[ package main; u
On Sat, Jan 30, 2010 at 16:16, Tim Bunce wrote:
> This is an update to the final plperl patch in the series from me.
>
> Changes in the original patch:
plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> - Ensure Safe container opmask is restored even if @EvalInSafe code
> throws an e
On Fri, Aug 29, 2008 at 1:16 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> In theory the above implementation of newNode should be a clear win,
> so I'm thinking this result must be an artifact of some kind. I'm
> going to go try it on PPC and HPPA machines next; does anyone want to
> try it on someth
On Thu, Sep 4, 2008 at 12:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think what the hash index patch really needs is some performance
> testing. I'm willing to take responsibility for the code being okay
> or not, but I haven't got any production-grade hardware to do realistic
> performance te
On Mon, Sep 8, 2008 at 2:24 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> HEAD actually gets this one wrong; in defiance of the documentation it
> returns 2000-09-07. So, it seems to me that the patch shifts the
> behaviour in the right direction.
>
> Barring actually teaching the code that some n
On Tue, Sep 9, 2008 at 6:46 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
>> <[EMAIL PROTECTED]> wrote:
>>> The use of palloc/pfree in this routine seems excessive. Does
On Sun, Sep 21, 2008 at 11:09 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> A possible objection to this plan is that if the column-level privileges
> patch doesn't get in, then we're left with a useless column in
> pg_attribute. But an always-null column doesn't cost much of anything,
> and we know t
On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names. This would make it easy to accept any flavour of marker,
> and the
On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Here is a contrib version of auto-explain.
> I'd like to add it the next commit-fest in September.
Here is my review:
*custom_guc_flags-0828.patch
It seems to be windows newline damaged? lots of ^M at the end of the
l
On Fri, Oct 31, 2008 at 07:48, David Fetter <[EMAIL PROTECTED]> wrote:
> Please find attached a patch which works in PL/Perl, the work having
> been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
> this would be generally surface-able to SQL, though. Any ideas?
I was assigned to r
On Thu, Oct 30, 2008 at 05:16, Tom Lane <[EMAIL PROTECTED]> wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
>> On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
>>> I would argue that it's already designed wrong if there's need for
>>> PL-specific implementation effort.
>
>> I'm not sure
On Thu, Oct 9, 2008 at 03:06, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Thanks for your reviewing, Alex.
> I applied your comments to my patch.
Sorry for the late reply! Somehow I missed this, saw it on the commit
fest wiki :)
>> *custom_guc_flags-0828.patch
>> My o
On Wed, Nov 5, 2008 at 16:00, Kevin Grittner
<[EMAIL PROTECTED]> wrote:
> An idea for a possible enhancement to PostgreSQL: allow creation of a
> temporary table without generating any disk I/O. (Creating and
> dropping a three-column temporary table within a database transaction
> currently gener
$ chmod 0600 ~/.postgresql/*
$ SSLVERIFY=cn ./psql junk -h bahdushka
psql (8.4devel)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
junk=#
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'1
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>> On Mon, Oct 20, 2008 at 05:50, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>> $ SSLVERIFY=cn ./psql junk -h 192.168.0.2
>> psql: server common name
DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=# \q
$ ./psql postgres -h 127.0.0.1
psql: server common name 'bahdushka' does not match hostname
'127.0.0.1'FATAL: no pg_hba.conf entry for host "127.0.0.1", user
"alex", database &q
On Thu, Nov 13, 2008 at 01:05, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> It means I will go ahead and apply it once I have looked it over once more.
>
> Thanks for review+testing!
>
> You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomor
On Thu, Oct 23, 2008 at 08:51, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
>> This patch adds a configuration option to pg_hba.conf for "clientcert".
>> This makes it possible to have different client certificate requirements
>> on different connections. It also makes sure t
On Sat, Nov 15, 2008 at 15:20, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> we do something like:
>
> + if (access(ROOT_CERT_FILE, R_OK))
> + {
> + ssl_loaded_verify_locations = false;
> +
> + /*
> + * If root cer
On Thu, Nov 13, 2008 at 05:31, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Attached patch implements client certificate authentication.
>
> I kept this sitting in my tree without sending it in before the
> commitfest because it is entirely dependent on the
> not-yet-reviewed-and-applied patch for
On Sat, Nov 15, 2008 at 17:39, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Err that really should be ereport(FATAL,
>
> I don't think that's a particularly user-friendly design.
>
> The behavior I'
On Mon, Nov 17, 2008 at 01:01, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>> Would cncert be a better auth_method name? As later we might have
>> different types of ssl client cert authenti
On Mon, Nov 17, 2008 at 05:31, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Magnus Hagander escribió:
>> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>
>>> My only concern is there is no way to specify the USER_CERT_FILE for
>
On Mon, Nov 17, 2008 at 03:04, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>> On Sat, Nov 15, 2008 at 17:39, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> 2. Root cert file present but we fail to load it: FATAL is probably okay
>>> here, but n
On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Something that's bothering me is that PGSSLKEY is inconsistent with the
> sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
> driver for specialized hardware AFAICT) from which the key is to be
> loaded, b
On Thu, Nov 20, 2008 at 21:45, Philip Warner <[EMAIL PROTECTED]> wrote:
>
> Sounds somewhat evil, I know, but I was wondering if it was even
> remotely possible with the current design?
>
> The reason: we are contemplating using pg_standy to create a
> warm-standby. It would be a bonus if we would
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Who anyone be opposed to "ssldir = path" as a connection option? Currently,
> there is no way to change the homedir method ~/.postgresql ... or am I
> missing something? I am willing to supply a patch.
You mean something li
On Fri, Dec 5, 2008 at 14:22, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>>
>> On Fri, Dec 5, 2008 at 13:58, Andrew Chernow <[EMAIL PROTECTED]> wrote:
>>>
>>> Who anyone be opposed to "ssldir = path" as a connection o
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
Submission review:
Is the patch in standard form? Yes
Does it apply cleanly to current HEAD? Yes (with fuzz)
Does it in
On Tue, Dec 9, 2008 at 01:20, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Dec 2008, Alex Hunsaker wrote:
>
>> (dual core machine, --enable-debug, --enable-cassert build)
>> pgbench -c 2 -T60 -n -f test.sql
>>
>> HEAD: tps = 9.674423
>> PATCH: tps =
On Mon, Dec 8, 2008 at 23:28, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
>
> "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>
>> I was assigned to review this.
>
> Thanks for your reviewing.
> I assume that the basic concepts are ok and focus of
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
> <[EMAIL PROTECTED]> wrote:
>> Here is an update version of contrib/pg_stat_statements.
>
> Hello again!
>
> I was assigned to review this.
On Mon, Dec 22, 2008 at 00:44, ITAGAKI Takahiro
wrote:
>
> "Alex Hunsaker" wrote:
>
>> A few comments:
>>
>> Is there a reason you add sourceText to QueryDesc? AFAICT you can do
>> ActivePortal->sourceText and it will always be populated correctly.
On Sat, Dec 27, 2008 at 11:50, Andrew Chernow wrote:
> Why does pqGetHomeDirectory have to succeed to use conn->sslrootcert. Maybe
> this should be an OR of the two since sslrootcert is not dependent on
> homedir?
>
> around line 970 src/interfaces/libpq/fe-secure.c
>
> if (conn->sslrootcert || pq
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
wrote:
> Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
look (you did fix the race/not protected by a spinlock you found
earlier right?) . And if all looks goo
On Mon, Dec 29, 2008 at 15:46, Alex Hunsaker wrote:
> On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
> wrote:
>> Here is an updated version of contrib/pg_stat_statements patch.
>
> Im going to do some more testing, give the typedef Chunk stuff another
> look (you did fix t
On Thu, Jan 1, 2009 at 17:28, Tom Lane wrote:
> "Alex Hunsaker" writes:
>> ... So Im going to mark it as
>> ready for commmiter.
>
> Has this patch been tested on Windows? (Or more generally, with
> EXEC_BACKEND?)
I was under the impression thats where Ita
On Thu, Jan 1, 2009 at 19:59, Tom Lane wrote:
> I wrote:
>> * in an EXEC_BACKEND situation, we re-execute
>> process_shared_preload_libraries() when starting a fresh backend
>> (but not in other kinds of child processes, which is why the other
>> problem is a problem). This means re-executing the
I just did a fresh import of my alpha database into 8.4 and noticed
that the size of the database had increased significantly:
8.4: 6.3G
8.3: 4.9G
Tracking it down the main difference seems to a toast tables namely this one:
ls -ltrh 8.3/base/16516/430156
-rw--- 1 postgres postgres 145M 2009
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker wrote:
> http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cdbits
... typoed that its
http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
--
Sent via pgsql-hack
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker wrote:
> My hunch is its related to
> http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
> or for the CVS inclined
> http::/archives.postgresql.org/pgsql-committers/2008-03/msg00121.php
>
&g
On Thu, Jan 1, 2009 at 22:44, Alex Hunsaker wrote:
> Looking at the patch we dont compress things > 1M anymore so I thought
> maybe I was hitting that. But no luck there are only 39 rows where
> the row size > 1M... With those 39 being about 22M each.
Oh my... 25 * 40 = 1000M
where die_id = 295;
$ ./pgbench -T60 -n -f q.sql
8.4: 1532.327546
8.3: 21.295657
Thats with 8.4 as a --enable-debug --enable-cassert build! (8.3 just
has --enable-debug)
> I'm not entirely convinced by Alex' analysis anyway; the only way
> those 39 large values explain t
On Fri, Jan 2, 2009 at 10:44, Robert Haas wrote:
> Here, we have a case where the space savings are potentially much
> larger, and the only argument against it is that someone might be
> disappointed in the performance of substring operations, if they
> happen to do any. What if they know that th
> in strategy_default_data from "1024 * 1024" to "INT_MAX", then
> re-load the table with the modified backend (or you could even
> just do "CREATE TABLE foo AS SELECT * FROM existing_table" and
> then compare sizes). If that puts the toast table size back
On Fri, Jan 2, 2009 at 17:22, Tom Lane wrote:
> A couple of other possibilities that seem a bit saner:
>
> 1. Use a self-organizing list: any time an entry is referenced,
> move it to front, and when you need a new entry take the oldest
> one off the back. I don't see a way to do that without a g
On Fri, Jan 2, 2009 at 18:23, Tom Lane wrote:
> "Alex Hunsaker" writes:
>> Its seems to me a linear list would make the "common" case where the
>> query is already in the list but we need to update the stats slow.
>
> No, the hashtable is still there for
On Fri, Jan 2, 2009 at 03:13, Magnus Hagander wrote:
> Andrew Chernow wrote:
>> Yes, the homedir variable is used again later in the function. homedir
>> could be invalid since pqGetHomeDirectory might not get called. Maybe
>> something like below would do the trick:
> How about this patch?
lo
On Fri, Jan 2, 2009 at 18:30, Tom Lane wrote:
> "Alex Hunsaker" writes:
>> On Fri, Jan 2, 2009 at 11:44, Tom Lane wrote:
>>> An easy way to prove or disprove the point would be to go into
>>> src/backend/utils/adt/pg_lzcompress.c, and change the second en
On Fri, Jan 2, 2009 at 20:30, Tom Lane wrote:
> One point that nobody seems to have focused on is whether Alex's
> less-compressed table is faster or slower to access than the original.
> I dunno if he has any easy way of investigating that for his typical
> query mix, but it's certainly a fair qu
On Fri, Jan 2, 2009 at 18:46, Tom Lane wrote:
>
> It would be fairly easy, I think, to add some reloption fields that
> would let these parameters be controlled on a per-table level.
+1
Or something easier that just lets you use PGLZ_Strategy strategy_always_data.
ALTER TABLE SET STORAGE ALWAYS
On Sat, Jan 3, 2009 at 09:37, Tom Lane wrote:
> I wrote:
>> ... This doesn't actually work in the current system.
>
> I have a solution for this, I think. I propose that guc.c only allow
> custom PGC_POSTMASTER variables to be created during
> process_shared_preload_libraries().
Sounds simple en
On Fri, Jan 2, 2009 at 20:20, Tom Lane wrote:
> I wrote:
>> * the startup/shutdown hooks will be installed in the postmaster
>> process, but the patch expects them to be executed in a child process.
>> I think nothing will happen.
>
> OK, I figured out what is happening there: the patch makes it w
On Fri, Jan 2, 2009 at 16:11, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Please find attached an updated patch for column-level privileges
>> which incorporates Alvaro's suggested changes and is updated to the
>> latest CVS HEAD.
Hi!
This gives me
aclchk.c: In fu
On Sat, Jan 3, 2009 at 20:47, Philip Warner wrote:
> Tom Lane wrote:
>> It would be fairly easy, I think, to add some reloption fields that
>> would let these parameters be controlled on a per-table level.
>> Per-column would be much more painful; do we really need that?
>>
>
> Another +1 on the p
On Sat, Jan 3, 2009 at 21:56, Philip Warner wrote:
> Alex Hunsaker wrote:
>> For the record I just imported a production database that sits at
>> about ~20G right now with *zero* size increase (rounding to the
>> nearest gigabyte). That's with basically the exact sam
On Sun, Jan 4, 2009 at 15:01, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Okay, it was basically fine except for the attached minor correction.
>> Warning: I intend to commit this patch fairly soon!
>
> This is the patch in its final form. I have included a few macros to
> simplify the wri
This patch lets you control 3 pg_lzcompress knobs on a per table basis
(note requires reloptions.patch)
compress_max_size: Controls the maximum size to be considered for
TOAST compression.
compress_min_rate: Minimum compression rate (0-100%) required for
TOAST compression to be used.
compress_suc
On Tue, Jan 6, 2009 at 06:43, Bruce Momjian wrote:
> Alex Hunsaker wrote:
>> This patch lets you control 3 pg_lzcompress knobs on a per table basis
>> (note requires reloptions.patch)
>
> I think we need to live with the TOAST changes for at least one release
> before we
On Tue, Jan 6, 2009 at 12:57, Stephen R. van den Berg wrote:
> Peter Eisentraut wrote:
>>(1) Compress everything within reason by default, causing slower retrieval, do
>>not offer substr optimization. [<= 8.3]
>
>>(2) Compress only up to 1 MB, causing faster retrieval, supporting substr
>>optimiza
ments, no?
>
> You know, I thought we discussed it as part of that patch, but the
> author was Vladimir Sitnikov, not the pg_stat_statement author, Alex
> Hunsaker, so I am just checking.
I assume you mean Itagaki-san not me :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 27, 2009 at 06:39, Grzegorz Jaskiewicz wrote:
> heh, sorry folks for the noise again :/
>
> There was a fair amount of false positives there - due to nature of Assert()
> macro. Mainly, since assert_enabled is a runtime variable, not a macro
> (which I sadly overlooked).
>
> So, hardcod
join
ordering. The example I gave involved removing Distinct and pushing
Limit through a join)
--
Alex Brasetvik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote:
> I'd go for the first of those, for sure. Testing attnotnull is
> significantly cheaper than enforcing a generic constraint expression,
> and NOT NULL is a sufficiently common case to be worth worrying about
> optimizing it.
When I looked at doing
On Thu, Nov 12, 2009 at 11:56, Bernd Helmle wrote:
> I've just started looking into this and wonder how this should look like.
IIRC another motivation for moving them into pg_constraint was we
could then give them names as required by the spec (unless I got mixed
up with defaults). Looking at th
On Mon, Nov 16, 2009 at 11:45, Tom Lane wrote:
> Alex Hunsaker writes:
>> FYI defaults have the same problem. Would it be awkward would it be
>> to use pg_constraint for the book keeping as well? [ and by that I
>> really mean ALTER TABLE ADD CONSTRAINT my_default DEFAU
While looking over the writable cte patch I noticed queries.sgml has
lots of things in the form "FROM". I tried various
googles to see if is some kind of sgml/xml shorthand for close the
last opened tag. But alas, nothing found. Bad google foo?
Should we change those to be the right closing ta
On Mon, Nov 16, 2009 at 20:41, Tom Lane wrote:
> Apparently --- it's perfectly legal in SGML. (I think not in XML.)
Cool. Thanks!
BTW anyone know how to escape < and > for google? I tried searching
for it-- but ran into a chick and egg situation. So the I tried
various forms of "google search
On Sun, Nov 15, 2009 at 14:27, Marko Tiikkaja
wrote:
> I wrote:
>>
>> Attached is the latest version of this patch.
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
-add some asserts to make sure places we use subplan
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
wrote:
>> Also, after reading through the previous threads; it was not
>> immediately obvious that you dealt with
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
>> only allowing selects or values at the top level of with.
>
> T
On Sat, Nov 21, 2009 at 16:07, David E. Wheeler wrote:
> On Nov 22, 2009, at 7:49 AM, Tom Lane wrote:
>
>> I'm thinking maybe we should remove -w. Comments?
>
> Have you tried it on the existing tests to see what happens?
For me there I get:
*the breaking in create_cast
*various things in foreig
Argh hit the wrong reply button...
-- Forwarded message --
From: Alex Hunsaker
Date: Wed, Nov 25, 2009 at 10:20
Subject: Re: [HACKERS] Writeable CTE patch
To: Marko Tiikkaja
On Mon, Nov 23, 2009 at 14:33, Marko Tiikkaja
wrote:
> Hi,
>
> Sorry for the delay, I
> BTW, anybody following the GIT mirror, the REL8_3_STABLE branch has been
> re-wound, you you'll probably have to force update it (git fetch -f) if
> you only accept fast forward updates on fetches (the default).
Thanks! now i can ditch the git.or.cz mirror
> And if you have patches based on
On Thu, Mar 27, 2008 at 5:34 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > BTW, anybody following the GIT mirror, the REL8_3_STABLE branch has been
> > re-wound, you you'll probably have to force update it (git fetch -f) if
> > you only accept fast forward up
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > Attached is a WIP patch I have been playing with in my spare time. It
> > should take care
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
> I was taking a look at this patch to add the pg_dump related changes. Just
> wanted to give you a heads up as this patch crashes if we run "make
> installcheck". Seems there is an issue in
On Wed, Apr 16, 2008 at 4:32 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008 15:22:31 -0700
>
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
>
> > On Wed, 16 Apr 2008 22:17:30 -
> > "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> >
> > > I don't think it's fair to s
On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Joshua D. Drake escribió:
>
> > That is an interesting idea. Something like:
> >
> > pg_restore -E "SET STATEMENT_TIMEOUT=0; SET MAINTENANCE_WORK_MEM=1G" ?
>
> We already have it -- it's called PGOPTIONS.
>
Ok but is n
On Tue, May 6, 2008 at 7:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > [ patch to fix behavior of inherited constraints ]
>
> Looking over this patch, I see that it introduces a syscache on
> pg_constrai
On Wed, May 7, 2008 at 12:20 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> Find attached a diff from v4-v5, and a full patch.
>
> src/backend/commands/tablecmds.c | 242
> +++-
>
> src/backend/utils/cache/syscache.c | 12 --
On Wed, May 7, 2008 at 8:28 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Brendan Jurd wrote:
> > On Thu, May 8, 2008 at 12:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > I think it would be helpful for us to provide an infrastructure where
>
On Wed, May 7, 2008 at 9:03 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
> > Plus it seems awkward to move a discussion thats taking place on
> > -hackers over to patches... Granted I could post to patches first,
> > wait an hour then send a
401 - 500 of 654 matches
Mail list logo
