On Tue, 23 May 2006, Tom Lane wrote:
I'm still thinking that the simplest explanation is that $PGDATA/pg_clog/
is on the NAS device. Please double-check the file locations.
I know that seems like an excellent candidate, but it really isn't, I swear.
In fact, you almost had me convinced the l
Jeff Frost <[EMAIL PROTECTED]> writes:
> I tried both pulling the plug on the CIFS server and unsharing the CIFS
> share,
> but pgbench continued completely unconcerned. I guess the failure mode of
> the
> NAS device in the customer colo must be something different that I don't yet
> know how
On Sun, 21 May 2006, Jeff Frost wrote:
So the chances of the original problem being archiver related are
receding...
This is possible, but I guess I should try and reproduce the actual problem
with the same archive_command script and a CIFS mount just to see what
happens. Perhaps the real r
On Mon, May 22, 2006 at 18:38:35 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > On Mon, May 22, 2006 at 10:23:28 +0200,
> > Albe Laurenz <[EMAIL PROTECTED]> wrote:
> >> In order to (efficiently) process a GROUP BY clause, you need a
> >> total order
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How expensive is this going to be, especially for huge numbers of rows?
Certainly cheaper than firing a per-row trigger.
> Would it be done for all queries, or just those with a per statement
> trigger, or only when explicitly requested?
Just when t
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
If there was more information than the tuplestore could keep in memory,
then a TIDstore might be faster, but only if it resulted in reading from
the heap sequentially, or very near it.
That's easily arranged, use a bitmap in
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> If there was more information than the tuplestore could keep in memory,
> then a TIDstore might be faster, but only if it resulted in reading from
> the heap sequentially, or very near it.
That's easily arranged, use a bitmap indexing data structure.
I
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Mon, May 22, 2006 at 10:23:28 +0200,
> Albe Laurenz <[EMAIL PROTECTED]> wrote:
>> In order to (efficiently) process a GROUP BY clause, you need a
>> total ordering on the data type that you group by, i.e. an ordering
>> such that for any two data x
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What's with the second workMem setting?
That's the second sort bucket for recently-dead tuples (which still have
to be indexed, but shouldn't be fed into the unique-checking sort).
We assume there won't be a lot of them, hence don't use
maintenance_work
On Sunday 21 May 2006 18:43, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > For those that haven't already seen it, this might give some extra
> > exposure to PostgreSQL wrt vulnerability research. Though I think nobody
> > will have a chance to find one (I just don't see how y
Jim C. Nasby wrote:
On Sun, May 21, 2006 at 02:58:17PM -0700, Josh Berkus wrote:
Actually, porting TSQL to PL/pgSQL would be very hard. I speak as an expert
TSQL developer. For example, most data manipulation in TSQL is done through
updatable cursors, something we don't currently support.
Martijn van Oosterhout wrote:
For high-end MSSQL shops, a high value is being able to trace and profile
(EXPLAIN) every client SQL command from the server side ... with plenty of
options for selective trace.
This would also be highly valuable to have in PostgreSQL.
Are we talking EXPLAIN (wh
On May 22, 2006, at 2:37 PM, Alvaro Herrera wrote:
Jim C. Nasby wrote:
Moving to -hackers
You forgot to actually do it apparently?
Sorry about posting the patch to -general, BTW. Anyway it was
committed
to the 8.1 branch, so it is included in the new release (8.1.4?)
Does this still o
Jim C. Nasby wrote:
> Moving to -hackers
You forgot to actually do it apparently?
Sorry about posting the patch to -general, BTW. Anyway it was committed
to the 8.1 branch, so it is included in the new release (8.1.4?)
> Does this still obey stats_command_string?
Yes.
I considered having the
Andrew Dunstan wrote:
imacat wrote:
But, on my i386 machine, I can build PL/Perl with static library
(libperl.a). But I can't do that on x86_64 anymore. Can somebody tell
me why, or where should I referring to?
Why do you want to do this? It works perfectly well with a shared lib,
Simon Riggs wrote:
There is not currently any way to make an existing table become a child
table of another table. I propose a TODO item to allow this:
ALTER TABLE childN INHERITS ( parent1, ... );
This would only succeed if all of the columns that would have been
inherited from all pa
OK, I created a "trigger" section and moved "referential integrity"
under "SQL commands".
---
Jim C. Nasby wrote:
> On Mon, May 22, 2006 at 03:11:14PM -0400, Bruce Momjian wrote:
> > Martijn van Oosterhout wrote:
> > -- Star
On Mon, 2006-05-22 at 14:25 -0400, April Lorenzen wrote:
> Postgresql partioning makes this all almost possible: the master
> automatically SELECTs from all the child tables - so it automatically
> recoginize the new ones, and no loss when the old ones are dropped.
>
> Just one thing would make i
imacat wrote:
But, on my i386 machine, I can build PL/Perl with static library
(libperl.a). But I can't do that on x86_64 anymore. Can somebody tell
me why, or where should I referring to?
Why do you want to do this? It works perfectly well with a shared lib,
and is probably more memo
Jim C. Nasby wrote:
On Mon, May 22, 2006 at 03:28:39PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
DROP
On Mon, May 22, 2006 at 10:23:28 +0200,
Albe Laurenz <[EMAIL PROTECTED]> wrote:
>
> In order to (efficiently) process a GROUP BY clause, you need a
> total ordering on the data type that you group by, i.e. an ordering
> such that for any two data x and y you have either x < y or x > x
> or x = y
On Sun, 21 May 2006 16:35:24 -0700 (PDT)
gede wawan <[EMAIL PROTECTED]> wrote:
> relocation R_X86_64_32 can not be used when making a shared object;
> recompile with -fPIC
May I ask how? I have tried to edit src/makefiles/Makefile.linux
and changed -fpic to -fPIC, but it does not help. Maybe
On Mon, May 22, 2006 at 08:54:20PM +0100, Simon Riggs wrote:
> On Mon, 2006-05-22 at 14:01 -0500, Jim C. Nasby wrote:
> > While setting up for the compressed sort testing...
> >
> > NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
> > "accounts_pkey" for table "accounts"
> > LOG:
On Mon, 2006-05-22 at 14:01 -0500, Jim C. Nasby wrote:
> While setting up for the compressed sort testing...
>
> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
> "accounts_pkey" for table "accounts"
> LOG: begin index sort: unique = t, workMem = 16384, randomAccess = f
> LOG:
Martijn van Oosterhout writes:
> I implemented a basic implementation using pg_lzcompress. It appears
> that pg_lzcompress is very, very slow. I was afraid that I'd made an
> infinite loop, but it was just really slow. Mind you, the overhead of
> each call might have been the problem, it was being
BTW, the test I ran this weekend ended up filling the disk, so I wasn't
able to get results. I hope to have results for a compressed sort that's
still larger than memory in the morning. Unfortunately I'm doing all
this on a machine I use for other things, so it's hard to do testing and
other things
On Mon, May 22, 2006 at 03:28:39PM -0400, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >
> >BEGIN;
> >-- Don't do the drop right now, because it might take awhile
> >ALTER TABLE tablename RENAME TO delete_tablename;
> >ALTER TABLE temporary_tablename RENAME TO tablename;
> >COMMIT;
> >DROP delete_
On Mon, May 22, 2006 at 03:14:18PM -0400, Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
> > On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > > ON table FOR EACH STATEMENT
> > > > EXECUTE PROCEDURE
On Mon, May 22, 2006 at 03:11:14PM -0400, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> -- Start of PGP signed section.
> > On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > > ON table FOR EACH STATEM
Jim C. Nasby wrote:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
DROP delete_tablename;
What if there are dependencies? Might be better to have a view, whic
I'm going to be offline for a few days but there are some things I've
tested in the meantime.
Once the compression level drops below 4-to-1 the overhead of zlib
becomes overwhelming compared to the savings. I'm not sure how common
that is, I basically filled a table for random data to get it that
On Mon, May 22, 2006 at 02:25:09PM -0400, April Lorenzen wrote:
> It comes up repeatedly that I need to load fresh data into a new
> table, build indexes and vacuum - then drop the old table and
> substitute the new.
Why are you vacuuming a brand new table? Just run analyze.
> Postgresql partion
On Mon, May 22, 2006 at 08:45:07PM +0200, Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
>
On Mon, May 22, 2006 at 08:56:14PM +0200, Dawid Kuroczko wrote:
> Also, assuming there is a "pginstall dbanme packagename" interface,
> a -contrib package should register all its subpackages within that
> system. So, you install postgresql-contrib, and then you can type:
>
> pg_package install my
Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
> > And that doesn't give you any informatio
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
> > And that
While setting up for the compressed sort testing...
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
"accounts_pkey" for table "accounts"
LOG: begin index sort: unique = t, workMem = 16384, randomAccess = f
LOG: begin index sort: unique = t, workMem = 16384, randomAccess = f
LO
On 5/22/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
> Except that apt doesn't work on all platforms. Though it would certainly
> make sense to look at lifting the framework for CPgAN from somewhere,
> rather than coding it ourselves.
A CPgAN would be a great idea in theory, but I have reservati
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > ON table FOR EACH STATEMENT
> > EXECUTE PROCEDURE funcname ( arguments )
>
> And that doesn't give you any information on the rows that were
> modified. Other
> On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote:
>> On 5/20/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
>> >The improvements to the installer are great, but there simply needs to
>> >be a packaged solution that adds more of the things people are very
>> >likely to use. From my under
It comes up repeatedly that I need to load fresh data into a new
table, build indexes and vacuum - then drop the old table and
substitute the new.
Deleting old and inserting new records is too slow - not to mention
the vaccuming. Loading with COPY, then building indexes, then
vacuuming is very fa
On Sat, May 20, 2006 at 02:29:01PM +0200, Dawid Kuroczko wrote:
> On 5/20/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
> >The improvements to the installer are great, but there simply needs to
> >be a packaged solution that adds more of the things people are very
> >likely to use. From my understandi
On Mon, May 22, 2006 at 05:06:47PM +0200, Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > > T-SQL has statement-level triggers, and they get used a lot (some big
> > > apps
> > > ONLY put code in triggers). Statement-level triggers are very effici
In article <[EMAIL PROTECTED]>,
Martijn van Oosterhout writes:
> On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
>> > T-SQL has statement-level triggers, and they get used a lot (some big apps
>> > ONLY put code in triggers). Statement-level triggers are very efficient
>> > for
>
On 5/22/06, Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > T-SQL has statement-level triggers, and they get used a lot (some big apps
> > ONLY put code in triggers). Statement-level triggers are very efficient for
> > maintaining aggregates; the c
Martijn van Oosterhout writes:
> The odd thing is that there are two paths defined, $localedir and
> $exp_localedir, which are not the same and pg_config.h gets one and
> pg_config_paths.h gets the other.
It looks to me like $localedir is literally "${prefix}/share/locale",
while exp_localedir ha
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > T-SQL has statement-level triggers, and they get used a lot (some big apps
> > ONLY put code in triggers). Statement-level triggers are very efficient for
> > maintaining aggregates; the closest PG has are rewrite rules.
>
> Yeah
On Sun, May 21, 2006 at 02:58:17PM -0700, Josh Berkus wrote:
> Mischa,
>
> > Somebody earlier was mentioning, why no automatic transformer from
> > Transact-SQL to PLPGSQL (maybe with a bunch of glue routines). The grammar
> > is not a problem, though you have to wonder at all the wired-in keyword
On Fri, May 19, 2006 at 01:03:08PM -0700, Mischa Sandberg wrote:
> >On Thursday 18 May 2006 12:38, Josh Berkus wrote:
> >>Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
> >>make *migration* easier for those who wake up and smell the BS, but
> >>migration can (and probabl
Martijn van Oosterhout writes:
> On Mon, May 22, 2006 at 10:55:59AM +0400, Victor B. Wagner wrote:
>> I've also unable to find useful description of DirectFunctionCallN
>> family of functions, which seems to be neccessary to call one 'C'
>> language PostgreSQL function from another.
>>
>> It is c
On Mon, May 22, 2006 at 12:17:33PM +0200, Peter Eisentraut wrote:
> LOCALEDIR is defined in
>
> src/port/pg_config_paths.h
> src/include/pg_config.h
>
> but one of them should be enough. (May be dependent on --enable-nls.) Which
> one should be removed?
I'd suggest the version in pg_config. B
Ühel kenal päeval, R, 2006-05-19 kell 11:29, kirjutas Mark Woodward:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Mark Woodward wrote:
> >>> Again, there is so much code for MySQL, a MySQL emulation layer, MEL
> >>> for
> >>> short, could allow plug and play compatibility for open source, an
> Try contrib/pg_trgm...
Tri-graphs are interesting, and I'll try to reconsider whether they fit or
not, ut I suspect that do not. (You are the second to recommend it)
Anything based on a word parser is probably not appropriate, the example I
first gave is a little misleading in that it is not th
LOCALEDIR is defined in
src/port/pg_config_paths.h
src/include/pg_config.h
but one of them should be enough. (May be dependent on --enable-nls.) Which
one should be removed?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Jaime Casanova wrote:
> suppose we have something like this:
>
> upd_views=# create table tabla1 (col1 point);
[...]
> then, this select will give an error:
>
> upd_views=# select col1, count(*) from tabla1 group by col1;
> ERROR: could not identify an ordering operator for type point
> HINT:
On Mon, May 22, 2006 at 10:55:59AM +0400, Victor B. Wagner wrote:
> BTW, what should I do if I want to submit entirely new directory into
> contrib - shall I make a patch against current source tree or just
> archive of this directory would do?
Diffs are better, unless it really is a lot of code.
56 matches
Mail list logo
