"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> You'd need two essentially equivalent versions of SearchSysCache, and
>> you'd lose the ability to make the error message identify what was being
>> searched for, so I vote no.
> Both arguments are not necessaril
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> You'd need two essentially equivalent versions of SearchSysCache, and
> you'd lose the ability to make the error message identify what was being
> searched for, so I vote no.
>
Both arguments are not necessarily true. This change is quite like what we
made
I forget whether the developer managed to get it working without doing any
table rewriting. In theory the table just needs to know that records that are
"missing" that column in the null bitmap should behave as if they have the
default value. But I seem to recall some headaches with that approach.
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > Renaming directories is nasty in CVS no matter which way you look at it - it
> > is one of the known bad limitations. You might preserve the history but you
> > could also break every existing repo copy. See
> > http://ximbiot.com/c
It's worth noting that on Darwin (on Apple hardware) gettimeofday is
never a syscall whereas on Linux (AFAIK), it always is.
On Jun 8, 2006, at 7:58 PM, Mark Kirkwood wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Wow, that is slow. Maybe a problem in the kernel? Perhaps
Josh Berkus writes:
> "Performs best" is pretty elusive. On Solaris 10, for example, fdatasync
> does best on pgbench on x86, but opendatasync does best on DBT2 on Sparc.
> I'm not certain we can really determine this with any accuracy.
Yeah, if it were easy we've have done it already :-(.
Tom Lane wrote:
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
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> Do you have a test case to reproduce this problem?
> According to the error message, the problem happens during reading
> pg_database. I just tried to plug in this line in mdread():
OK, patch applied for this.
Tom, JD,
> No, that only tells you if the various alternatives *work*. Not which
> one performs best.
"Performs best" is pretty elusive. On Solaris 10, for example, fdatasync
does best on pgbench on x86, but opendatasync does best on DBT2 on Sparc.
I'm not certain we can really determine th
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Renaming directories is nasty in CVS no matter which way you look at it - it
> is one of the known bad limitations. You might preserve the history but you
> could also break every existing repo copy. See
> http://ximbiot.com/cvs/manual/cvs-1.11.15/cvs_
Marc G. Fournier said:
> On Thu, 8 Jun 2006, Tom Lane wrote:
>
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> 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
On Thu, 8 Jun 2006, Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
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
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Doesn't this exist in:
> src/tools/fsync?
No, that only tells you if the various alternatives *work*. Not which
one performs best.
regards, tom lane
---(end of broadcast)---
T
Doesn't this exist in:
src/tools/fsync?
Do we just need to make it more user friendly?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 19
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
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 libpgc
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> 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.
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
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
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
"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
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*
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
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
"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.
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
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
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
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
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
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
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:
> 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 wrote:
> postgres=# explain analyze select count(*) from accounts;
>QUERY PLAN
>
> Aggregate (cost=2890.00
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
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: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
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, 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
Ü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
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
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)---
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
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
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 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
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
Ü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
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
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?
Ü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 <[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
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)---
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
Hi guy,
Where I con download Postgres 8.2 from ?
Regards
Milen
---(end of broadcast)---
TIP 6: explain analyze is your friend
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
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:
> 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
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
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
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
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
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
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
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
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:
> 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
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
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
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
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
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
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
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
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:
> "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:
> 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
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
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)--
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
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.
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
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
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_
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.
"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
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
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.
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
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
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 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
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
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
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
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
"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
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
"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 :-(
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
"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
1 - 100 of 116 matches
Mail list logo
