On Thu, 7 Jun 2007, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > Was there some change in functionality reason for renaming is_array_type
> > to type_is_array?
>
> Just to sync style with type_is_enum ... there were more of the latter
> than the former.
OK, so it is safe to just
Jeremy Drake <[EMAIL PROTECTED]> writes:
> Was there some change in functionality reason for renaming is_array_type
> to type_is_array?
Just to sync style with type_is_enum ... there were more of the latter
than the former.
> It broke compilation of fulldisjunctions,
Sorry, but we change interna
Was there some change in functionality reason for renaming is_array_type
to type_is_array? It broke compilation of fulldisjunctions, which I build
and run regression tests on in my sandbox to keep it getting too horribly
broken with respect to current HEAD. I got it to build and pass its
regressi
On Sat, Jun 02, 2007 at 01:37:19PM +, Tasneem Memon wrote:
> We can make the system ask the user as to what membership degree s/he wants
> to get the values, but we don?t want to make the system interactive, where a
> user gives a membership degree value of his/her choice. These operators are
On 6/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Perhaps a reasonable compromise could work like this: at the first point
in a transaction where a temp file is created, choose a random list
element, and thereafter advance cyclically for the duration of that
transaction. This ensures within-transac
Michael Fuhr wrote:
> Is vacuuming any table supposed to zero the statistics for all
> shared tables?
Huh, certainly not. In any case, I think the problem may be related to
the fact that stats for shared tables are kept in a separate hash from
regular tables.
I'll investigate the issue tomorrow
Is vacuuming any table supposed to zero the statistics for all
shared tables? Doesn't that have implications for autovacuum? The
example below is in 8.2.4 but I'm seeing similar behavior in 8.1.9
and 8.3devel. Additionally, in 8.3devel doing anything that queries
or modifies a shared table seems
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
> > .) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
> > is considered to be "later" than any other xid.
>
> So you are bumping FirstNormalTransactionId up by one for this?
>
> You're assuming then that we will "free
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That statement seems perfectly accurate to me.
> Considering an index of a,b if I search for b I would expect that the
> planner could use the index.
It can. Whether it will think that's a good idea is another question
entirely,
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
I guess where I got confused is:
http://www.postgresql.org/docs/8.1/static/indexes-multicolumn.html
And explicitly:
A multicolumn B-tree index can be used with query conditions that
involve any subset of the index's columns, but t
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> I guess where I got confused is:
>>
>> http://www.postgresql.org/docs/8.1/static/indexes-multicolumn.html
>>
>> And explicitly:
>>
>> A multicolumn B-tree index can be used with query conditions that
>> involve any subset of the index's columns,
Joshua D. Drake wrote:
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Assume the following:
index on: (id, adate)
constraint CHECK(adate > '01-01-2007' AND adate < '04-01-2007');
The planner will not use the index li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, June 05, 2007 10:28:58 +0300 Devrim GÜNDÜZ
<[EMAIL PROTECTED]> wrote:
>
> Hi Marc,
>
> Is there a written procedure about creating tarballs? I'd like to start
> working on 8.3 RPMs and I want to know what I should to to create a
> t
Alvaro Herrera wrote:
Simon Riggs wrote:
On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if
On Wed, 2007-06-06 at 17:14 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> > > Florian G. Pflug wrote:
> > > > Work done so far:
> > > > -
> > > > .) Don't start autovacuum and bgwriter.
> > >
> > > Do table s
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
> .) Added a new GUC operational_mode, which can be set to either
> readwrite or readonly. If it is set to readwrite (the default),
> postgres behaves as usual. All the following changes are only
> in effect if operational_mode
Simon Riggs wrote:
> On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> > Florian G. Pflug wrote:
> > > Work done so far:
> > > -
> > > .) Don't start autovacuum and bgwriter.
> >
> > Do table stats used by the planner get replicated on a PITR slave? I
> > assume s
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It looks to me like we could eliminate the conflict if we invented a new
>> polymorphic pseudotype called "anynonarray" or some such, which would
>> act like anyelement *except* it would not match an array.
> ...
> On the contrary, I w
On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> Florian G. Pflug wrote:
> > Work done so far:
> > -
> > .) Don't start autovacuum and bgwriter.
>
> Do table stats used by the planner get replicated on a PITR slave? I
> assume so, but if not, you would need autov
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe I am missing something, but the only such construct I see in
>> SQL2003 is concatenation of arrays of equal rank. There is nothing
>> corresponding to array_prepend or array_append.
> Well, I've never claimed to be particularly goo
Magnus Hagander wrote:
>Hannes Eder wrote:
>> Is it worth doing this the "Perl-way" and using File::Find? If so, I
can
>> work an a patch for that.
>>
> It's certainly cleaner that way, but I don't find it a major issue.
But I'd
> rather see that fix than the other one.
Here we go. See attach
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If not I have missed something - why would the syslogger be trying to
write to its output (possibly for the second time) regardless of what
Log_destination is set to?
You're mistaken: within the syslogger process, stderr doe
On Wed, 6 Jun 2007, Heikki Linnakangas wrote:
The original patch uses bgwriter_all_max_pages to set the minimum rate. I
think we should have a separate variable, checkpoint_write_min_rate, in KB/s,
instead.
Completely agreed. There shouldn't be any coupling with the background
writer parame
On Wed, 2007-06-06 at 19:25 +0200, Florian G. Pflug wrote:
> Thats what I currently do - the xip array on the slave is sized to
> hold max_connections entries (Actually, it's max_connections +
> max_prepared_xacts I think). The problem occurs exactly if those
> values are set too small on the slave
On Wed, 6 Jun 2007, Tom Lane wrote:
If we don't know how to tune them, how will the users know?
I can tell you a good starting set for them to on a Linux system, but you
first have to let me know how much memory is in the OS buffer cache, the
typical I/O rate the disks can support, how many
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In the long run maybe we should choose some other name for the
array_append and array_prepend operators to avoid the confusion with
concatenation. It seems to me that "concatenation" normally implies
"stringing together sim
Jeff Davis wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Since the slaves needs to track an Snapshot in shared memory, it cannot
resize that snapshot to accomodate however many concurrent transactions
might have been running on the master. My current plan is
Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
Yes - everything that get wal-
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
>.) Since the slaves needs to track an Snapshot in shared memory, it cannot
> resize that snapshot to accomodate however many concurrent transactions
> might have been running on the master. My current plan is to detect if
>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If not I have missed something - why would the syslogger be trying to
> write to its output (possibly for the second time) regardless of what
> Log_destination is set to?
You're mistaken: within the syslogger process, stderr doesn't point to
the same
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
---(end of broadcast)-
I have just been staring for some time at the logic in
src/backend/utils/error/elog.c:send_message_to_server_log(), which
contains this fragment near the end:
/* Write to stderr, if enabled */
if ((Log_destination & LOG_DESTINATION_STDERR) || whereToSendOutput
== DestDebug)
{
#if
> > While I agree, that 2 might be a good compromise with low risc for
> > now, I think that toasting all rows down to ~512 bytes is too
narrowly
> > targeted at not reading wider columns.
>
> Well, it is summarized here:
>
> http://momjian.us/expire/TOAST/SUMMARY.html
>
> It made non-T
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Well, it is summarized here:
>
> http://momjian.us/expire/TOAST/SUMMARY.html
>
> It made non-TOAST access 2x faster, but TOAST 7x slower, and that seemed
> like a good compromise.
Is this still testing with all data fitting in RAM?
--
Gregor
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I do have a plan B if people don't want to rename the operators, though.
>> It looks to me like we could eliminate the conflict if we invented a new
>> polymorphic pseudotype called "anynonarray" or some such, which would
>> act like a
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> GUC summary and suggested default values
>
> checkpoint_write_percent = 50 # % of checkpoint interval to
> spread out
> writes
> checkpoint_write_min_rate = 1000 # minimum I/O rate to wr
Zeugswetter Andreas ADI SD wrote:
>
> > > No, you misunderstood. Bruce was suggesting changing the target to
> 512.
> > > That means if a row is wider than ~2k, toaster will try to toast
> until
> > > the base row is
> > > ~512 bytes. I would not do that part for 8.3.
> >
> > OK, what do you su
Tom Lane wrote:
> I do have a plan B if people don't want to rename the operators, though.
> It looks to me like we could eliminate the conflict if we invented a new
> polymorphic pseudotype called "anynonarray" or some such, which would
> act like anyelement *except* it would not match an array.
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In the long run maybe we should choose some other name for the
>> array_append and array_prepend operators to avoid the confusion with
>> concatenation. It seems to me that "concatenation" normally implies
>> "stringing together similar o
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> GUC summary and suggested default values
>
> checkpoint_write_percent = 50 # % of checkpoint interval to
> spread out writes
> checkpoint_write_min_rate = 1000 # minimum I/O rate to wr
Hi
This is a description of the GSoC work I've so for on readonly
support for PITR slaves. I'm looking for any kind of comments
on this - I want to make sure that I work in a direction that
the community approves.
Work done so far:
-
.) Added a new GUC operational_mode, which can
I'm again looking at way the GUC variables work in load distributed
checkpoints patch. We've discussed them a lot already, but I don't think
they're still quite right.
Write-phase
---
I like the way the write-phase is controlled in general. Writes are
throttled so that we spend the spe
> > No, you misunderstood. Bruce was suggesting changing the target to
512.
> > That means if a row is wider than ~2k, toaster will try to toast
until
> > the base row is
> > ~512 bytes. I would not do that part for 8.3.
>
> OK, what do you suggest for 8.3? Attached are my suggestion
> to use
> For example in 8.2 this is mapped to array_prepend:
>
> regression=# select 'x'::text || array['aa','bb','cc'];
>?column?
> --
> {x,aa,bb,cc}
> (1 row)
>
> but with the experimental code you get textcat:
>
> catany=# select 'x'::text || array['aa','bb','cc'];
> ?column?
> ---
> For example in 8.2 this is mapped to array_prepend:
>
> regression=# select 'x'::text || array['aa','bb','cc'];
>?column?
> --
> {x,aa,bb,cc}
> (1 row)
>
> but with the experimental code you get textcat:
>
> catany=# select 'x'::text || array['aa','bb','cc'];
> ?column?
> -
45 matches
Mail list logo
