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
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 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 the
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 li
[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
> encod
"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 who
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
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 "
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 brea
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
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 rele
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
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? Some
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
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
-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
> > >
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 o
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 w
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 someon
http://pastebin.ca/845696
added schema ...
On Jan 7, 10:21 pm, [EMAIL PROTECTED] wrote:
> 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;
>
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 implem
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 re
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 ,
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 th
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 seg
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 idxFTI=to_t
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
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
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 sys
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 tse
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
-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;
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 th
"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
"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
>>
>> T
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 i
-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 unde
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 produ
-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:
>
>
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 vi
-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
"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
"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
> diffe
>>> 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)
>
> whic
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 s
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 con
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 t
>>> 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
>> mit
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 alr
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
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 windows
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 unneede
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?
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 so
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, 2008-0
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
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 cr
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
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 (
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 tim
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 s
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 ma
62 matches
Mail list logo
