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?
-
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 512 and a
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
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 write
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 objects, which
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.
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 suggest for 8.3?
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 write
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 anyelement
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?
--
Gregory Stark
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-TOAST access
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)
{
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
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
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
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
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
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 similar
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
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, 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
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
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 attached patch.
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 good at
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 autovac to do
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 would think
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 not,
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 is
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 stats used by the
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
-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
tarball.
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 listed
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 the index is
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 the
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, and one
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 freeze replay
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
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
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
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
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
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 internal
43 matches
Mail list logo
