On Jun 8, 2006, at 15:38 , Albert Cervera Areny wrote:
However, I've realized that managing foreign keys with my own
PL/SQL or C function isn't possible as I need DEFERRED checks which
are
currently only available for foreign keys.
I don't know enough about your situation to be sure if thi
On Wed, 2006-06-07 at 17:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2006-06-07 at 16:56 -0400, Tom Lane wrote:
> >> Certainly the removal of timing
> >> is not going to convert an intolerable EXPLAIN ANALYZE runtime into an
> >> acceptable one;
>
> > I disagre
> > > But that's entirely inconsistent with the way inherited tables
work
> > > in general.
> >
> > I don't see any basis for that conclusion. The properties of a
table
> > are set when it's created and you need to do pretty explicit ALTERs
to
> > change them.
>
> It just seems weird for:
>
Rodrigo Hjort wrote:
How about those "pg_ts*" tables, which are specific for a database? Will
they serve to the whole cluster?
No, it plans per database only.
If you need in all database, you can install tsearch2 into template1, so all
newly created database will have the same tsearch2 conf
> The solution to the foreign key problem seems easy if I
> modify PostgreSQL implementation and take off the ONLY word
> from the SELECT query, but it's not an option for me, as I'm
I think that the ONLY was wrong from day one :-(
The default in other areas is table including childs.
(N
Ühel kenal päeval, N, 2006-06-08 kell 08:38, kirjutas Albert Cervera
Areny:
> Hi,
> after starting this thread
> http://archives.postgresql.org/pgsql-hackers/2006-05/msg00222.php, I thought
> I'd finally go for making foreign keys my own way instead of trying to patch
> PostgreSQL. However
Ühel kenal päeval, K, 2006-06-07 kell 17:45, kirjutas Jim C. Nasby:
> Plus, if the only issue here is in fact the long-running transaction for
> vacuum, there's other ways to address that which would be a lot less
> intrusive than doing something like going to 64 bit XIDs. IIRC, in 8.2
> vacuum wi
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> Imho the op should only choose that path if he wants to fill the table
> before adding the inheritance. It makes no sense to add columns with default
> values to existing rows of the child table, especially when you inherit the
> defaults
I can't find any standard api to remove a single specific dependency. It seems
normally dependencies are only removed when dropping objects via
performDeletion.
Should I just put a scan of pg_depend in ATExecDropInherits or should I add a
new function to pg_depend or somewhere else to handle dele
Ühel kenal päeval, N, 2006-06-08 kell 09:32, kirjutas Greg Stark:
> "Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>
> > Imho the op should only choose that path if he wants to fill the table
> > before adding the inheritance. It makes no sense to add columns with default
> > values to e
Josh Berkus wrote:
Tom,
What's the consensus on this? Nobody else has chimed in, so I'm
inclined to do no more on the gounds of insufficient demand. Let's
decide before too much bitrot occurs, though.
+1 :)
+1
We were talking about this on IRC, and I feel that if we'
Greg Stark wrote:
>
> I can't find any standard api to remove a single specific dependency. It seems
> normally dependencies are only removed when dropping objects via
> performDeletion.
Huh, and can't you just drop an inheritance entry with performDeletion?
Maybe what you should do is add suppor
> On Wed, Jun 07, 2006 at 07:07:55PM -0400, Mark Woodward wrote:
>> I guess what I am saying is that PostgreSQL isn't "smooth," between
>> checkpoints and vacuum, it is near impossible to make a product that
>> performs consistently under high load.
>
> Have you tuned the bgwriter and all the vacuu
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2006-06-07 at 17:28 -0400, Tom Lane wrote:
>> The overhead seems to be on the order of a couple tens of percent usually.
>> I don't see how that makes the difference between an EXPLAIN ANALYZE you
>> can run and one you can't.
> Well, thats not my
Larry Rosenman wrote:
well, the changes didn't help.
I've pulled ALL the cronjobs from firefly.
consider it dead.
Since it is an outlier, it's not useful.
OK, I am marking firefly as retired. That means we have no coverage for
Unixware.
cheers
andrew
---(e
Mark Woodward wrote:
On Wed, Jun 07, 2006 at 07:07:55PM -0400, Mark Woodward wrote:
I guess what I am saying is that PostgreSQL isn't "smooth," between
checkpoints and vacuum, it is near impossible to make a product that
performs consistently under high load.
Have you tuned the bgwriter and all
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> There are roughly 420 calls of SearchSysCache() and 217 of which are just
> report "cache lookup failed". Shall we put the elog in the SearchSysCache
> itself?
You'd need two essentially equivalent versions of SearchSysCache, and
you'd lose the ability
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> >
> > I can't find any standard api to remove a single specific dependency. It
> > seems
> > normally dependencies are only removed when dropping objects via
> > performDeletion.
>
> Huh, and can't you just drop an inheritance ent
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> The solution to the foreign key problem seems easy if I
>> modify PostgreSQL implementation and take off the ONLY word
>> from the SELECT query, but it's not an option for me, as I'm
> I think that the ONLY was wrong from day one :-(
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Do you mean that in newer versions ALTER TABLE ADD COLUMN will change
> existing data without asking me ?
>
> That would be evil!
>
> Even worse if ALTER TABLE ALTER COLUMN SET DEFAULT would do the same.
postgres=# alter table test add b integer defa
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I was recently involved in a project where we had to decrease the
> checkpoint_timeout . The problem was, that the database was performing
> so many transactions that if we waiting for 5 minutes, checkpoint would
> take entirely too long.
Seems li
Greg Stark <[EMAIL PROTECTED]> writes:
> Come to think of it it's pretty strange that you can drop an inherited
> constraint from a child. And doing an experiment it seems you can also DROP
> NOT NULL on a child which is also pretty strange.
Yeah. I think we had agreed that this is a bug. Note t
What type are bare strings considered if they haven't been cast? I'm curious as
to how the first case is of size 5, and how the last case is 301...
decibel=# select pg_column_size('test');
5
decibel=# select pg_column_size('test'::varchar);
8
decibel=# select pg_colum
Tom Lane wrote:
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
The solution to the foreign key problem seems easy if I
modify PostgreSQL implementation and take off the ONLY word
from the SELECT query, but it's not an option for me, as I'm
I think that the ONLY was wrong from da
On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
> > > It was awfully annoying for users when that feature was missing.
> > > Any non-linearities in the user interface like this
> > > end up being surprises and annoyances for users.
> >
> > I would be *really*, *really*, *really* annoy
On Thu, 2006-06-08 at 10:27 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2006-06-07 at 17:28 -0400, Tom Lane wrote:
> >> The overhead seems to be on the order of a couple tens of percent usually.
> >> I don't see how that makes the difference between an EXPLAIN ANALY
On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:
> OK there does seem to be some demand for this, so I will rework the
> patch, and hope to get it done by feature freeze - it has bitrotted
> with 7 merge conflicts, including the grammar file, so I need to
> look carefully at that. P
Hannu Krosing <[EMAIL PROTECTED]> writes:
> If the aim is to *only* avoid transaction wraparound, then maybe we
> could introduce VACUUM FREEZE ONLY; which never removes any old tuples,
> but instead just marks them by setting xmin=xmax for them, in addition
> to its freezing of live-and-visible-to
Jim C. Nasby wrote:
> What type are bare strings considered if they haven't been cast? I'm curious
> as
> to how the first case is of size 5, and how the last case is 301...
>
> decibel=# select pg_column_size('test');
> 5
"unknown". This seems to be a cstring (i.e. length 5 consi
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
I was recently involved in a project where we had to decrease the
checkpoint_timeout . The problem was, that the database was performing
so many transactions that if we waiting for 5 minutes, checkpoint would
take entirely too long.
Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > What type are bare strings considered if they haven't been cast? I'm
> > curious as
> > to how the first case is of size 5, and how the last case is 301...
> >
> > decibel=# select pg_column_size('test');
> > 5
>
> "unknown". This se
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
> > But I seem to recall some headaches with that approach.
>
> What happens if you
>
> ALTER TABLE ... ADD new_column int DEFAULT 1;
> ALTER TABLE ... ALTER new_column SET DEFAULT 2;
Ah ye
Maybe putting it on pgFoundry?
Hmm, it's a variant. We can create project 'tsearch2_dict' and there I'll place
contrib module which will make all Snowball stemmers. Right now I'm working on
supporting OpenOffice's dictionaries in tsearch2, so it will be simple to add it
to packaging system.
On Thu, Jun 08, 2006 at 12:19:49PM -0400, Greg Stark wrote:
>
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > On Thu, Jun 08, 2006 at 11:42:49AM -0400, Greg Stark wrote:
> > > But I seem to recall some headaches with that approach.
> >
> > What happens if you
> >
> > ALTER TABLE ... ADD new_
On Thu, Jun 08, 2006 at 09:13:33AM -0700, Joshua D. Drake wrote:
> Tom Lane wrote:
> >"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >>I was recently involved in a project where we had to decrease the
> >>checkpoint_timeout . The problem was, that the database was performing
> >>so many transact
Greg Stark wrote:
> Well I'm not actually deleting anything. The dependency is between the two
> tables and I don't want to delete either of the tables.
>
> Perhaps what should really be happening here is that there should be
> dependencies from the pg_inherit entry to the two tables rather than
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Come to think of it it's pretty strange that you can drop an inherited
> > constraint from a child. And doing an experiment it seems you can also DROP
> > NOT NULL on a child which is also pretty strange.
>
> Yeah.
David Fetter wrote:
On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:
OK there does seem to be some demand for this, so I will rework the
patch, and hope to get it done by feature freeze - it has bitrotted
with 7 merge conflicts, including the grammar file, so I need to
look car
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I managed uniqueness using normal indexes and ins/upd triggers on all
> child tables:
Do I need to point out the race-condition problems in this?
regards, tom lane
---(end of broadcast)--
Simon Riggs <[EMAIL PROTECTED]> writes:
> So far we have myself, Kevin, Martijn and Luke all saying there is a
> distortion or a massive overhead caused by EXPLAIN ANALYZE.
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg00954.php
> http://archives.postgresql.org/pgsql-patches/2006-05/msg
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The implementation I had in mind was to add columns similar to attinhcount
>> and attislocal to pg_constraint.
> Hm that would be simpler. That still leaves NOT NULL as a bit of a headache.
Yeah, I think we would wan
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> "unknown". This seems to be a cstring (i.e. length 5 considering the
> trailing \0)
Yeah. "unknown" used to have the same representation as "text", ie
varlena, but I changed it recently because I realized that the normal
thing we do with an "unknown"
Greg Stark <[EMAIL PROTECTED]> writes:
> Perhaps what should really be happening here is that there should be
> dependencies from the pg_inherit entry to the two tables rather than from one
> table to the other.
This seems unlikely to still have the correct semantics (DROP on child
is OK, DROP on
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>
> > Well I'm not actually deleting anything. The dependency is between the two
> > tables and I don't want to delete either of the tables.
> >
> > Perhaps what should really be happening here is that there should be
> > dependenci
I wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
>> question is what we do when one is not available.
> The least bad alternative I've heard is to let EXPLAIN ANALYZE print
> out stats-so-far if the query is canceled by contro
On Thu, Jun 08, 2006 at 12:34:54PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
> >On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:
> >
> >>OK there does seem to be some demand for this, so I will rework the
> >>patch, and hope to get it done by feature freeze - it has bitrot
Jim C. Nasby wrote:
Important as you are, "one swallow does not make a summer".
On the other hand, unless we want the lists filling up with a bunch of
+1 posts, it's probably better to assume that unless someone objects a
patch would be accepted.
What happened was that Tom objected
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm a bit confused about what pg_depends entries would be necessary then. If
> there's something like this there:
> Child Table <--(AUTO)-- pg_inherit entry --(NORMAL)-> Parent Table
I think that would work, but it seems pretty baroque. pg_inherit
entries
Andrew,
> What happened was that Tom objected to (or at least queried the need
> for) the patch on the grounds that it was bloat that nobody had asked
> for. And when I asked I wasn't exactly deluged with requests to commit,
> so I concluded that it was not generally wanted.
Did you poll on -hack
Tom Lane wrote:
-- do it again to ensure fully cached
bench=# select count(*) from accounts;
Short summary:
Does running a query only twice really insure that a result is cached?
It seems not to be the case for seq-scans on Linux.
I think this may matters to the discussions about a readahe
Tom Lane <[EMAIL PROTECTED]> writes:
> After we've printed the results, we have a bit of a problem: if
> ExplainCancelPending is set, we now need to abort the transaction. It
> would not do at all to allow an incompletely executed UPDATE to commit.
> I experimented with throwing an elog() at the
Josh Berkus wrote:
Andrew,
What happened was that Tom objected to (or at least queried the need
for) the patch on the grounds that it was bloat that nobody had asked
for. And when I asked I wasn't exactly deluged with requests to commit,
so I concluded that it was not generally wanted.
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW ... are you intending to renumber inhseqno entries of remaining
> pg_inherits items after DROP INHERITS? Which seqno will be assigned
> by ADD INHERITS? This seems like another area in which DROP/ADD will
> not be a complete no-op.
I assigned inhseqno
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> Would it be possible to make a whole new protocol message for EXPLAIN results?
I'm really unwilling to get into that. For one thing, that would
absolutely positively break *all* use of EXPLAIN from un-fixed clients
Andrew Dunstan wrote:
> Josh Berkus wrote:
> >Andrew,
> >
> >>What happened was that Tom objected to (or at least queried the need
> >>for) the patch on the grounds that it was bloat that nobody had asked
> >>for. And when I asked I wasn't exactly deluged with requests to commit,
> >>so I concluded
I think what he meant was "a separate EXPLAIN-CANCEL message" on a
cancel-type connection, which would be completely backwards compatible.
Old clients simply wouldn't be able to use the special EXPLAIN cancel,
just like it is now.
On Thu, June 8, 2006 3:01 pm, Tom Lane wrote:
> Gregory Stark <[EMA
Greg Stark <[EMAIL PROTECTED]> writes:
> It's not a precise noop in database internal data structures, but I don't see
> any user-visible effects switching around seqnos would have. But maybe there's
> something I don't know about?
It'll affect the order in which pg_dump lists the parents, which w
Ron Mayer <[EMAIL PROTECTED]> writes:
> Does running a query only twice really insure that a result is cached?
> It seems not to be the case for seq-scans on Linux.
Should work for tables small enough to fit into the shared_buffers
arena. I wouldn't necessarily assume it for large tables.
No
Josh Berkus writes:
> This has been a problem in the past. I'd generally ask that, if a patch
> which was discussed on -hackers gets rejected on -patches, that discussion
> be brought back to -hackers. Often the people who supported the original
> feature are not on -patches and then are unpl
Tom Lane wrote:
> Josh Berkus writes:
> > This has been a problem in the past. I'd generally ask that, if a patch
> > which was discussed on -hackers gets rejected on -patches, that discussion
> > be brought back to -hackers. Often the people who supported the original
> > feature are not on
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> > Would it be possible to make a whole new protocol message for EXPLAIN
> > results?
>
> I'm really unwilling to get into that. For one thing, that would
> absolutely posi
Tom Lane wrote:
> A possible objection to this is that running a query inside a
> subtransaction might have different/worse performance than running it
> at top level. I don't recall any severe bottlenecks of that kind but
> that doesn't mean there aren't any (Alvaro, any comments?)
Nope, nothin
Hi guy,
Where I con download Postgres 8.2 from ?
Regards
Milen
---(end of broadcast)---
TIP 6: explain analyze is your friend
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > It's not a precise noop in database internal data structures, but I don't
> > see
> > any user-visible effects switching around seqnos would have. But maybe
> > there's
> > something I don't know about?
>
> It'll
It does not yet exist. When it is released you will be able to download
it from www.postgresql.org. That is some months away.
cheers
andrew
Milen Kulev wrote:
Hi guy,
Where I con download Postgres 8.2 from ?
Regards
Milen
---(end of broadcast)---
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> It'll affect the order in which pg_dump lists the parents, which will
>> affect the order in which the columns are created on dump and reload.
> Hm, if column order is important for table with multiple parents then yo
Ühel kenal päeval, N, 2006-06-08 kell 12:09, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > If the aim is to *only* avoid transaction wraparound, then maybe we
> > could introduce VACUUM FREEZE ONLY; which never removes any old tuples,
> > but instead just marks them by setting
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
Greg Stark <[EMAIL PROTECTED]> writes:
It's not a precise noop in database internal data structures, but I don't see
any user-visible effects switching around seqnos would have. But maybe there's
something I don't know about?
Andrew,
> It does not yet exist. When it is released you will be able to download
> it from www.postgresql.org. That is some months away.
I would have just said "We don't know. If you can figure it out, let us
know what's in 8.2, it will save us a lot of arguing."
--
--Josh
Josh Berkus
Postg
Ühel kenal päeval, N, 2006-06-08 kell 11:42, kirjutas Greg Stark:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > Do you mean that in newer versions ALTER TABLE ADD COLUMN will change
> > existing data without asking me ?
> >
> > That would be evil!
> >
> > Even worse if ALTER TABLE ALTER COLU
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I remember that discussion, but I'm surprised that something got
> implemented and accepted into core with so many unsolvable
> problems/logical inconsistencies/new pitfalls.
The current behavior of ALTER ADD COLUMN & SET DEFAULT is per SQL spec.
If you
On a separate note. The one major remaining piece here is in constraints. I'm
thinking what I have to check is that every constraint present on the parent
table is present on the child tables. And I'm thinking I should do that by
looking at the constraint's textual definition (consrc).
This doesn
On Thu, Jun 08, 2006 at 01:07:44PM -0700, Josh Berkus wrote:
> Andrew,
>
> > It does not yet exist. When it is released you will be able to download
> > it from www.postgresql.org. That is some months away.
>
> I would have just said "We don't know. If you can figure it out, let us
> know what'
On Thu, 2006-06-08 at 13:51 -0400, Tom Lane wrote:
> I wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
> >> question is what we do when one is not available.
>
> > The least bad alternative I've heard is to let EXPLAIN ANAL
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> It'll affect the order in which pg_dump lists the parents, which will
> >> affect the order in which the columns are created on dump and reload.
>
> > Hm, if column order is
Hannu Krosing <[EMAIL PROTECTED]> writes:
> for example - to be consistent, one should also make "ALTER TABLE ALTER
> COLUMN col SET DEFAULT x" change each "default" value, no ?
er, I think that is in fact a no.
--
greg
---(end of broadcast)---
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> So? They'll get re-merged with the parent column during CREATE TABLE
>> anyway.
> But merged columns that are defined locally still appear in the position they
> were defined locally. Not with the other inherited col
Ühel kenal päeval, N, 2006-06-08 kell 16:30, kirjutas Greg Stark:
> On a separate note. The one major remaining piece here is in constraints. I'm
> thinking what I have to check is that every constraint present on the parent
> table is present on the child tables. And I'm thinking I should do that
On Thu, 2006-06-08 at 12:56 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So far we have myself, Kevin, Martijn and Luke all saying there is a
> > distortion or a massive overhead caused by EXPLAIN ANALYZE.
> > http://archives.postgresql.org/pgsql-hackers/2006-03/msg00954.php
Simon Riggs <[EMAIL PROTECTED]> writes:
> So the timing is clearly responsible for the additional time I'm
> personally experiencing and very likely to be that for others also.
Well, that's certainly unsurprising, but the question is why it's such
a large overhead for you when it's not on other ap
On Thu, Jun 08, 2006 at 04:44:10PM -0400, Greg Stark wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > for example - to be consistent, one should also make "ALTER TABLE ALTER
> > COLUMN col SET DEFAULT x" change each "default" value, no ?
>
> er, I think that is in fact a no.
Yeah... onc
On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> So? They'll get re-merged with the parent column during CREATE TABLE
> >> anyway.
>
> > But merged columns that are defined locally still appear in the positio
On Thu, Jun 08, 2006 at 04:30:22PM -0400, Greg Stark wrote:
> Or maybe I should insist that a matching constraint name be present *and* that
> the source text match? That's more of a pain to code though.
That could also break some partitioning schemes; I don't think it's a
given that parents and c
Simon Riggs wrote:
> postgres=# explain analyze select count(*) from accounts;
>QUERY PLAN
>
> Aggregate (cost=2890.00
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> So the timing is clearly responsible for the additional time I'm
>> personally experiencing and very likely to be that for others also.
>
> Well, that's certainly unsurprising, but the question is why it's such
> a large overhead for you
Simon Riggs <[EMAIL PROTECTED]> writes:
> Based on the test case Tom shows, I think we need to enforce that ADD
> INHERITS will barf if the columns are not in exactly the order they
> would have been in if we add done a CREATE ... INHERITS followed by a
> DROP INHERITS.
This seems overly strong; i
Tom Lane wrote:
> If anyone else is still following this discussion, could you try the
> test case Simon gave a bit earlier (select count(*) from 10-row
> table, check \timing with and without explain analyze)? If we could get
> a clearer picture of which platforms show the problem and which
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tried on two machines. The first (Turion64 laptop) gives 44-45 ms for
> the SELECT, and 50-51 ms for the EXPLAIN ANALYZE.
> The second machine, desktop Celeron 533, gives 197-200 ms for the SELECT
> and 788-790 for the EXPLAIN ANALYZE. I guess this is
Simon Riggs wrote:
Based on the test case Tom shows, I think we need to enforce that ADD
INHERITS will barf if the columns are not in exactly the order they
would have been in if we add done a CREATE ... INHERITS followed by a
DROP INHERITS. That wouldn't be a problem if we just say to people, if
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > Tom Lane <[EMAIL PROTECTED]> writes:
> > >> So? They'll get re-merged with the parent column during CREATE TABLE
> > >> anyway.
> >
> > > But merged colu
On Thu, Jun 08, 2006 at 04:58:07PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So the timing is clearly responsible for the additional time I'm
> > personally experiencing and very likely to be that for others also.
>
> Well, that's certainly unsurprising, but the question
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tried on two machines. The first (Turion64 laptop) gives 44-45 ms for
> > the SELECT, and 50-51 ms for the EXPLAIN ANALYZE.
>
> > The second machine, desktop Celeron 533, gives 197-200 ms for the SELECT
> > and 788-790 for the EXPLA
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The powerbook tests were not very repeatable at 100,000 rows, so I
> bumped up to 1M. The results still aren't very repeatable...
Hmm, I suspect you pushed it into the realm where it's doing actual
I/O ... which we don't want for this particular test.
Hello,
I read this as:
1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto
2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_cryp
Just tested 2 windows boxes, both running 8.1.3 and XP SP2.
P4 2.8G desktop 47ms297ms
Pentium M 2G laptop 40ms240ms
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasi
Greg Stark <[EMAIL PROTECTED]> writes:
> Or maybe I should insist that a matching constraint name be present *and* that
> the source text match? That's more of a pain to code though.
Yeah, that's what I'd go with. I believe that there are bits of the
system (probably in pg_dump) that look *only*
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> That could also break some partitioning schemes; I don't think it's a
> given that parents and children have matching constraints, and afaik a
> parent can have constraints that a child doesn't.
Not unless you drop the inherited constraint; the fact tha
On Thu, Jun 08, 2006 at 05:32:36PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The powerbook tests were not very repeatable at 100,000 rows, so I
> > bumped up to 1M. The results still aren't very repeatable...
>
> Hmm, I suspect you pushed it into the realm where it's
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Wow, that is slow. Maybe a problem in the kernel? Perhaps something
> similar to this:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/index.html#1282
Yeah, that's a pretty interesting thread. I came across something
similar on a Red Hat inter
Joshua D. Drake wrote:
Hello,
I read this as:
1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto
err "are now"
2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus l
1 - 100 of 116 matches
Mail list logo
