Greg Smith wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the source code,
which they've only done to 8.2.4. Even that doesn't seem to be
production-quality and it's not clear how that will
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 29 Dec 2007 14:40:29 -0500 (EST)
Greg Smith [EMAIL PROTECTED] wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the
Greg Smith wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
they've has the potential to be we... As I recall the individual
made a reasonable effort to introduce the work that he was doing to the
community.
After a bit of hindsight research, I think SE-PostgreSQL suffered from
two timing
As suggested, I tested a VACUUM FULL ANALYZE with 128MB shared_buffers
and 512 MB reserved for maintenance_work_mem (on a 32 bit machine with 4
GB RAM). That ought to leave more than enough space for other processes
in the system. Again, the system fails on the VACUUM with the following
error
On Wed, 2008-01-02 at 17:56 +, Simon Riggs wrote:
Like it?
Very cool :-)
One additional thought: what about a kind of segment fill factor ?
Meaning: each segment has some free space reserved for future
updates/inserts of records in the same range of it's partitioning
constraint. And when
Joshua D. Drake wrote:
SELECT oid::regclass FROM pg_class WHERE
reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
oid | pg_temp_24.tmp_isp_blk_chk
The hack to get this cleaned up was to connect about 2 dozen times (to
get to slot 24) with psql via different sessions and create temp
Hi Csaba,
Csaba Nagy wrote:
One additional thought: what about a kind of segment fill factor ?
Meaning: each segment has some free space reserved for future
updates/inserts of records in the same range of it's partitioning
constraint. And when inserting/updating you put the new record into the
We are running the binary distribution, version 8.2.5-1, installed on
Windows XP Pro 32 bit with SP2. We typically run postgres on linux, but
have a need to run it under windows as well. Our typical admin tuning
for postgresql.conf doesn't seem to be as applicable for windows.
Doug
On Sun,
On Mon, 2008-01-07 at 13:59 +0100, Markus Schiltknecht wrote:
However, for tables which don't fit the use case of SE, people certainly
don't want such a fill factor to bloat their tables.
Sure, but it could be configurable and should only be enabled if the
table is marked as partitioned on
On Mon, 2008-01-07 at 14:20 +0100, Markus Schiltknecht wrote:
Why is that? AFAIUI, Segment Exclusion combines perfectly well with
clustering. Or even better, with an upcoming feature to maintain
clustered ordering. Where do you see disadvantages such an optimization
for sequential scans?
Hi,
Csaba Nagy wrote:
Sure, but it could be configurable and should only be enabled if the
table is marked as partitioned on some condition...
As I'm regarding SE as an optimization, I disagree here.. As all
optimizations, SE should conceptually be reasonably close to cost-less
when
Tom Lane wrote:
Sokolov Yura [EMAIL PROTECTED] writes:
create or replace function add_group(grp anyarray, ad anyelement, size int4)
returns anyarray
language plpgsql
...
create aggregate build_group(anyelement, int4) (
SFUNC= add_group,
STYPE = anyarray
);
ERROR: argument declared
On Jan 7, 2008 2:40 PM, Michael Akinde [EMAIL PROTECTED] wrote:
As suggested, I tested a VACUUM FULL ANALYZE with 128MB shared_buffers
and 512 MB reserved for maintenance_work_mem (on a 32 bit machine with 4
GB RAM).
My Apologies if my question seems redundant and something you have already
On Sun, Jan 6, 2008 at 7:20 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
There was a serious performance regression in OUTER JOIN planning
going from 8.2.4 to 8.2.5. I know Tom came up with some patches to
mitigate the issues
Doug Knight wrote:
We are running the binary distribution, version 8.2.5-1, installed on
Windows XP Pro 32 bit with SP2. We typically run postgres on linux,
but have a need to run it under windows as well. Our typical admin
tuning for postgresql.conf doesn't seem to be as applicable for
Hi,
The system we are building is intended to be utilized in a number of
different applications, so the testing we are doing is primarily
directed at stressing the system by running it through its paces and
uncovering any weaknesses. I prefer to find as many problems as possible
now, rather
On Sat, Jan 05, 2008 at 08:02:41PM +0100, Markus Schiltknecht wrote:
Well, management of relations is easy enough, known to the DBA and most
importantly: it already exists. Having to set up something which is
*not* tied to a relation complicates things just because it's an
additional
On Mon, Jan 07, 2008 at 10:40:23AM +0100, Michael Akinde wrote:
As suggested, I tested a VACUUM FULL ANALYZE with 128MB shared_buffers
and 512 MB reserved for maintenance_work_mem (on a 32 bit machine with 4
GB RAM). That ought to leave more than enough space for other processes
in the
On Fri, Jan 4, 2008 at 6:46 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
8.2 (at least at branch tip, can't say for sure about earlier
dot-releases)
8.2.4 and 8.2.5 both behave this way.
f2 | f3 | f1
++
53 || 53
(1 row)
which I claim is
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I didn't have any luck reproducing either of these behaviors --- maybe
it's data-dependent. Can you extract a test case?
I haven't been able to reproduce this either but I produced an entirely
different problem:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 09:18:24 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
SELECT oid::regclass FROM pg_class WHERE
reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
oid | pg_temp_24.tmp_isp_blk_chk
The hack
Gregory Stark [EMAIL PROTECTED] writes:
On the other hand we can't just ignore all vacuums because someone could issue
a manual vacuum inside a transaction (I think?).
Doh, ignore this. sigh.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce
Joshua D. Drake wrote:
SELECT oid::regclass FROM pg_class WHERE
reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
oid | pg_temp_24.tmp_isp_blk_chk
The hack to get this cleaned up was to connect about 2 dozen times
(to get to slot 24) with psql via different sessions and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Ah -- interesting. This is a known issue, but we haven't found a
solution yet.
Is there bug number?
I assume it is this TODO item:
o Prevent
On Mon, 07 Jan 2008 10:57:53 -0500, Andrew Sullivan wrote:
Note that you should almost never use VACUUM FULL unless you've really
messed things up. I understand from the thread that you're just testing
things out right now. But VACUUM FULL is not something you should _ever_
need in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 07 Jan 2008 17:33:53 +0100
Holger Hoffstaette [EMAIL PROTECTED] wrote:
On Mon, 07 Jan 2008 10:57:53 -0500, Andrew Sullivan wrote:
Note that you should almost never use VACUUM FULL unless you've
really messed things up. I understand
Hi,
Andrew Sullivan wrote:
On Sat, Jan 05, 2008 at 08:02:41PM +0100, Markus Schiltknecht wrote:
Well, management of relations is easy enough, known to the DBA and most
importantly: it already exists. Having to set up something which is
*not* tied to a relation complicates things just because
Joshua D. Drake [EMAIL PROTECTED] writes:
On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
I assume it is this TODO item:
o Prevent long-lived temporary tables from causing frozen-xid
advancement starvation
The problem is that
Gregory Stark [EMAIL PROTECTED] writes:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
I assume it is this TODO item:
o Prevent long-lived temporary tables from causing frozen-xid
advancement
On Monday 07 January 2008 09:10:24 Joshua D. Drake wrote:
On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Ah -- interesting. This is a known issue, but we haven't found a
solution yet.
Is there bug number?
I assume it is this TODO item:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 10:37:18 -0800
Darcy Buskermolen [EMAIL PROTECTED] wrote:
1. I had to manually vacuum because we had already hid xidStoplimit.
2. Postgres has been restarted multiple times and it made zero
difference.
E.g; PostgreSQL
On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote:
Does anything speak against letting the DBA handle partitions as relations?
Yes: it doesn't solve the problem I have, which is that I don't want to have
to manage a whole bunch of tables. I want one table, and I want to be
I am using tsearch2 with pgsql 8.2.5 and get the following error when
calling to_tsvector :
translation failed from server encoding to wchar_t
My database is UTF8 encoded and the data sent to to_tsvector comes
from a bytea column converted to text with
encode(COLUMN, 'escape').
In 8.1 with
Michael Akinde [EMAIL PROTECTED] writes:
As suggested, I tested a VACUUM FULL ANALYZE with 128MB shared_buffers
and 512 MB reserved for maintenance_work_mem (on a 32 bit machine with 4
GB RAM). That ought to leave more than enough space for other processes
in the system. Again, the system
http://pastebin.ca/845670
This url provides a testcase ...
fisrt pass :
= UPDATE dbmail_messageblks SET idxFTI=to_tsvector('simple',
encode(messageblk, 'escape')) where messageblk_idnr = 12949;
ERROR: translation failed from server encoding to wchar_t
second pass :
= UPDATE dbmail_messageblks
Darcy Buskermolen [EMAIL PROTECTED] writes:
After a fresh start of postgres, there should be no temp tables, so would a
work around to this at least be at postmaster start to (for a lack of a
better pseudo code ) DROP SCHEMA pg_temp* CASCADE; before coming up in
interactive mode?
The
Found something interesting with this testcase.
update fails after SELECT query.
Can anyone confirm this ???
dbname= UPDATE dbmail_messageblks SET idxFTI=to_tsvector('simple',
encode(messageblk, 'escape')) where messageblk_idnr = 12949;
UPDATE 1
dbname= UPDATE dbmail_messageblks SET
Andrew Sullivan wrote:
On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote:
...the requirements: no single tuple in the segment may be
significantly out of the average bounds. Otherwise, the min/max gets
pretty useless and the segment can never be excluded.
The segment can
Joe Conway [EMAIL PROTECTED] writes:
Did you want me to work on this? I could probably put some time into it
this coming weekend.
I'll try to get to it before that --- if no serious bugs come up this
week, core is thinking of wrapping 8.3.0 at the end of the week, so
it'd be nice to have this
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of the week,
Please give the packagers and other people one more week break between
two releases. We all had a busy weekend.
Regards,
--
Devrim GÜNDÜZ ,
On 2008-01-07, Tom Lane [EMAIL PROTECTED] wrote:
The real question that Josh's report brings up to me is why the heck was
there an orphaned temp table? Especially if it was only a toast table
and not the linked regular temp table? Something happened there that
should not have.
The regular
You'll get better response if you don't hijack threads. :) Also,
there's nothing in here that describes what the benefits of this
change are.
On Jan 1, 2008, at 2:09 PM, Manolo _ wrote:
Hi to all.
This mail is aimed at asking some suggestion to face PostgreSQL
(PG) development to
Well, sorry for hijacking... ummm how did I do that?
Anyway I'll thank you for giving a sign of life when I was almost loosing
my hopes to get any kind of answer from -hackers.
I suppose the lack of answers was due to the way I wrote my mail. At that
moment I supposed that at least someone
Devrim G?ND?Z wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of the week,
Please give the packagers and other people one more week break between
two releases. We all had a busy weekend.
Hi,
Andrew Sullivan wrote:
On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote:
Does anything speak against letting the DBA handle partitions as relations?
Yes: it doesn't solve the problem I have, which is that I don't want to have
to manage a whole bunch of tables. I want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 19:06:27 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the
Hi,
On Mon, 2008-01-07 at 19:06 -0500, Bruce Momjian wrote:
We have thousands of people waiting for the 8.3 release.
Really? How did you get this statistic?
...and IIRC, our motto is Release when it is ready, not release
because thousands ppl are waiting for it.
Regards,
--
Devrim GÜNDÜZ ,
On Monday 07 January 2008 16:06:27 Bruce Momjian wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of the week,
Please give the packagers and other people one more
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2008-01-07, Tom Lane [EMAIL PROTECTED] wrote:
The real question that Josh's report brings up to me is why the heck was
there an orphaned temp table? Especially if it was only a toast table
and not the linked regular temp table? Something
Hi,
On Mon, 2008-01-07 at 19:06 -0500, Bruce Momjian wrote:
It seems odd to hold up 8.3 because the packagers are too busy.
... and read my e-mail again. I wrote:
Please give the packagers and other people one more week break...
I did not say just the packagers. You give almost no time to
On Jan 8, 2008 1:04 AM, [EMAIL PROTECTED] wrote:
Well, sorry for hijacking... ummm how did I do that?
Anyway I'll thank you for giving a sign of life when I was almost loosing
my hopes to get any kind of answer from -hackers.
Don't forget that we're just a few days/weeks of 8.3 release so
Joshua D. Drake wrote:
Hi,
On Mon, 2008-01-07 at 17:12 -0500, Tom Lane wrote:
if no serious bugs come up this week, core is thinking of wrapping
8.3.0 at the end of the week,
Please give the packagers and other people one more week break
between two releases. We all had
Devrim G?ND?Z wrote:
-- Start of PGP signed section.
Hi,
On Mon, 2008-01-07 at 19:06 -0500, Bruce Momjian wrote:
It seems odd to hold up 8.3 because the packagers are too busy.
... and read my e-mail again. I wrote:
Please give the packagers and other people one more week break...
I
Tom Lane wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2008-01-07, Tom Lane [EMAIL PROTECTED] wrote:
The real question that Josh's report brings up to me is why the heck was
there an orphaned temp table? Especially if it was only a toast table
and not the linked regular temp
Bruce Momjian [EMAIL PROTECTED] writes:
I am not saying we are ready to release but if we determine the source
code is ready I would like to avoid more delay because the packagers
aren't ready.
It may be moot anyway. Now that I've caught up on today's email,
this thread looks like we have
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jan 07, 2008 at 07:16:35PM +0100, Markus Schiltknecht wrote:
Does anything speak against letting the DBA handle partitions as relations?
Yes: it doesn't solve the problem I have, which is that I don't want to have
to manage a whole bunch of
[EMAIL PROTECTED] writes:
I am using tsearch2 with pgsql 8.2.5 and get the following error when
calling to_tsvector :
translation failed from server encoding to wchar_t
My database is UTF8 encoded and the data sent to to_tsvector comes
from a bytea column converted to text with
Alvaro Herrera wrote:
Tom Lane wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2008-01-07, Tom Lane [EMAIL PROTECTED] wrote:
The real question that Josh's report brings up to me is why the heck was
there an orphaned temp table? Especially if it was only a toast table
and not the
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Hmm ... that would be strange. Off-the-cuff idea: we introduced code to
advance relfrozenxid in CLUSTER, TRUNCATE and table-rewriting forms of
ALTER TABLE. Perhaps the problem is that we're neglecting to update it
for the toast table there.
Gregory Stark wrote:
I also don't understand how this proposal deals with the more common use case
of unloading and loading data. Normally in partitioned tables we build the
data in a side table until the data is all correct then load it as a
partition. If you treat it as a lower-level object
On Tue, 08 Jan 2008, [EMAIL PROTECTED] wrote:
Well, sorry for hijacking... ummm how did I do that?
You replied to a post instead of creating a new, unrelated e-mail. It
is different.
Just try to use threaded mode of your e-mail client and you'll get
the idea.
Regards
Tometzky
--
...although
61 matches
Mail list logo
