Hello,
Sorry if it's wrong list for the question. Could you suggest some tweaks
to the PostgreSQL 7.2.1 to handle the following types of tables faster?
Here we have table "stats" with something over one millon records.
Obvious "SELECT COUNT(*) FROM stats " takes over 40 seconds to execute,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The Artistic License doesn't even qualify as Free Software as far as the
> FSF is concerned.
Errr, http://www.fsf.org/licenses/license-list.html lists it as not
only Free Software but GPL-compatible.
Mike.
---(end of broadca
Just making sure that I haven't screwed up anything plugging in amavis ...
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
got it...
what's amivis ?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
> Sent: Friday, August 02, 2002 10:17 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Does this go out?
>
>
>
> Just making sure that I haven't screwed up an
anti-virus software ... see http://www.amavis.org ...
On Fri, 2 Aug 2002, Jeff MacDonald wrote:
> got it...
>
> what's amivis ?
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
> > Sent: Friday, August 02, 2002 10:17 AM
> >
On Thu, 2002-08-01 at 22:39, Curt Sampson wrote:
> On 1 Aug 2002, Greg Copeland wrote:
>
> > For some reason,
> > many of the developers are under the impression that even if code is
> > never touched, it has a very high level of effort to keep it in the code
> > base. That is, of course, comple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> OK, we need all the interfaces to properly handle schemas within the
> next month. However, we don't have psql working properly yet. Once we
> get psql working, we can show examples of the changes we made and the
> other interfaces can use that
On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
>
> Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> is applications of plain old built-in-C functions and operators.
I thought part of the justification for this was for the OpenACS
guys; don't they write everyt
On Fri, 2 Aug 2002, Andrew Sullivan wrote:
> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
> >
> > Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> > is applications of plain old built-in-C functions and operators.
>
> I thought part of the justification for
On Fri, 2002-08-02 at 09:28, Marc G. Fournier wrote:
> On Fri, 2 Aug 2002, Andrew Sullivan wrote:
>
> > On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
> > >
> > > Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> > > is applications of plain old built-in-C func
times change if you do
"SELECT COUNT(1) FROM stats" ?
--
:: Sergio A. Kessler ::
Linux user #64005 - http://counter.li.org
"Yaroslav Dmitriev" <[EMAIL PROTECTED]> escribió en el mensaje
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hello,
>
> Sorry if it's wrong list for the question. Could yo
Yuva,
The results make sense to me. The left outer join functionality in Postgres
is explained as follows:
LEFT OUTER JOIN returns all rows in the qualified Cartesian product (i.e.,
all combined rows that pass its ON condition), plus one copy of each row in
the left-hand table for which there wa
> "Marc" == Marc G Fournier <[EMAIL PROTECTED]> writes:
Marc> On Fri, 2 Aug 2002, Andrew Sullivan wrote:
>> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote: > >
>> Actually, plpgsql is pretty expensive too. The thing to be
>> benchmarking > is applications of plain o
Matthew Tedder <[EMAIL PROTECTED]> wrote:
> For most web sites MySQL seems to work fine, but overall PostgreSQL offers
> more capabilites so why build upon a limited base such as MySQL?
> Does anyone here have any idea as to why so many people select MySQL when
> both systems are open sourced?
S
Curt Sampson wrote:
> I'm still waiting to find out just what advantage table inheritance
> offers. I've asked a couple of times here, and nobody has even started
> to come up with anything.
Table inheritance offers data model extensibility. New (derived) tables
can be added to the system, and
Hi,
> I am wondering if we could have a configure-time or install-time
> option to make pg_shadow (and pg_group I guess) be database-local
> instead of installation-wide. I am not sure about the implications
> of this --- in particular, is the notion of a database owner still
> meaningful? How
Some weeks ago i wrote about one problem(called as
"Bug of PL/pgSQL parser"):
"eutm" <[EMAIL PROTECTED]> writes:
> Dear Sirs!:)I encounted one small problem,working with
> PostgreSQL 7.3devel.It can look a
> bit strange,but i have to use whitespaces in names of
databases,tables,fields
> and s
On 29 Jul 2002 18:27:40 MDT, the world broke into rejoicing as
Stephen Deasey <[EMAIL PROTECTED]> said:
> Curt Sampson wrote:
>> I'm still waiting to find out just what advantage table inheritance
>> offers. I've asked a couple of times here, and nobody has even
>> started to come up with anythin
> Well, if you also have soundcard_products, in your example you could have a
> product which is both a networkcard AND a soundcard. No way to restrict
> that a product can be only one 'subclass' at a time... If you can make that
> restriction using the relational model, you can do the same as wit
On Fri, Aug 02, 2002 at 12:35:10PM -0400, Daniel Wickstrom wrote:
>
> On the other hand, all of the web server stuff is implemented on Aolserver
> which uses Tcl as a scripting language.
I think this is why I was confused. Thanks, all.
A
--
Andrew Sullivan
On Fri, 2002-08-02 at 13:53, Jeff Davis wrote:
> > Well, if you also have soundcard_products, in your example you could have a
> > product which is both a networkcard AND a soundcard. No way to restrict
> > that a product can be only one 'subclass' at a time... If you can make that
> > restriction
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
>> Actually, plpgsql is pretty expensive too. The thing to be benchmarking
>> is applications of plain old built-in-C functions and operators.
> I thought part of the justification for this wa
I count about seventy occurrences of this code pattern:
/* keep system catalog indices current */
if (RelationGetForm(pg_rewrite_desc)->relhasindex)
{
Relationidescs[Num_pg_rewrite_indices];
CatalogOpenIndices(Num_pg_rewrite_indices, Name_pg_rewrite_indices,
> An even more radical approach is to get rid of the hardwired index name
> lists in indexing.h, and instead expect CatalogOpenIndices to make use
> of the index OID lists that are maintained by the relcache (since 7.1 or
> so). Then the typical call would reduce to
>
> CatalogUpdateIndexes(
I wonder if we actually did the right thing with this.
For example:
select cast('ab' as char(1));
Using sql92's definitions, I read TD as
a fixed length character string and
SD as the same.
Which means I think the section that
comes into play is:
SQL92 6.10 GR5 c ii
ii) If the length in ch
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Then the typical call would reduce to
>>
>> CatalogUpdateIndexes(Relation, HeapTuple);
> This would be great. Anyway to take it one step further and make it
> transparent? Hide it in heap_insert / update?
No, that would be quite inappropriate. The co
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I wonder if we actually did the right thing with this.
> ...
> Wouldn't that mean the operation is supposed to succeed with
> diagnostic information since it's a completion condition not
> an exception condition?
Hm. You are right: an explicit cast to
On Thu, Aug 01, 2002 at 01:41:49PM -0400, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Consistently name server-side internal functions
OK, good start of discussion is define groups of the PostgreSQL
functions:
1/ Extern compatible functions
The functions compatible with stand
> 2/ PostgreSQL specific functions used in standard SQL operations
>
> (the function works with standard data and not load it from
> internal PostgreSQL stuff).
>
> For example convert(), all datetype function like int(). The name
> convenition must be like names in group 1/
> > For example convert(), all datetype function like int(). The name
> > convenition must be like names in group 1/
>
> FYI, I have been proposing SQL99 compatible convert(). I would like to
> add it if no one objects.
No objection, but what does it do out of interest? Will it cause a
b
> Here we have table "stats" with something over one millon records.
> Obvious "SELECT COUNT(*) FROM stats " takes over 40 seconds to execute,
> and this amount of time does not shorten considerably in subsequent
> similar requests. All the databases are vacuumed nightly.
Doing a row count requ
On Thu, 2002-08-01 at 20:41, Dann Corbit wrote:
> I have discussed the idea of contributing our Win32 work to the
> PostgreSQL project with management.
>
> We have also converted all of the utilities (initdb, psql, pg_dump,
> pg_restore, pg_id, pg_passwd, etc.)
>
> Management is (rightfully) con
On Fri, Aug 02, 2002 at 05:38:37PM +0900, Tatsuo Ishii wrote:
> > 2/ PostgreSQL specific functions used in standard SQL operations
> >
> > (the function works with standard data and not load it from
> > internal PostgreSQL stuff).
> >
> > For example convert(), all datetype functi
On Thu, 2002-08-01 at 23:20, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > > I will object to any scheme that makes any characters in the user name
> > > > magic. Two reasons: First, do it right, make a separate column.
> > > > Second, several tools use URI syntax to specify data sources.
> Hmm. I think this consideration boils down to whether the WHERE clause
> can give different results for rows that appear equal under the rules of
> UNION/EXCEPT/INTERSECT. If it gives the same result for any two such
> rows, then it's safe to push down; otherwise not.
>
> It's not too diffic
On Fri, 2002-08-02 at 08:55, Curt Sampson wrote:
> On Fri, 2 Aug 2002, Marc G. Fournier wrote:
>
> > Isn't inheritance kinda one of those things that is required in order to
> > be consider ourselves ORBDMS, which we do classify our selves as being?
>
> Well, it depends on what you call an ORDBM
On Fri, 2002-08-02 at 05:39, Curt Sampson wrote:
> Because SQL99 is non-relational in many ways, so I guess they
> figured making it non-relational in one more way can't hurt.
>
> I mean come on, this is a language which started out not even
> relationally complete!
Could you point me to some pu
On 2 Aug 2002, Hannu Krosing wrote:
> Is _The Third Manifesto_ available online ?
No. It's a book, and not a terribly small one, either.
http://www.amazon.com/exec/obidos/ASIN/0201709287/
> Could you brief me why do they discourage a syntactical frontent to a
> feature that is trivially im
On 2 Aug 2002, Hannu Krosing wrote:
> Could you point me to some pure relational languages ?
> Preferrably not pure academic at the same time ;)
The QUEL and PostQUEL languages used in Ingres and the old Postgres were
rather more "relational" than SQL.
> BTW, what other parts of SQL do you cons
On Fri, 2002-08-02 at 12:15, Curt Sampson wrote:
> On 2 Aug 2002, Hannu Krosing wrote:
>
> > Is _The Third Manifesto_ available online ?
>
> No. It's a book, and not a terribly small one, either.
>
> http://www.amazon.com/exec/obidos/ASIN/0201709287/
>
> > Could you brief me why do they di
* Hannu Krosing <[EMAIL PROTECTED]> [020802 06:32]:
> Your argument can as well be used against VIEWs - whats the point of
> having them, when they can trivially be implemented using ON XXX DO
> INSTEAD rules.
Well, at least on PostgreSQL it makes a difference. We allow views to
have permissions
Christopher Kings-Lynne wrote:
>Doing a row count requires a sequential scan in Postgres.
>
>Try creating another summary table that just has one row and one column and
>is an integer.
>
>
I have THREE summary tables derived from "stats" with different levels
of aggregation. They work quite
I checked out a fresh copy of the dev code today, and get the following
errors when doing a configure with no options followed by a make all:
make[7]: Entering directory `/usr/local/src/pgsql/src/utils'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../src/include -I/usr/local/inc
Ok. This is what I wanted to hear, but I had assumed someone decided to
put it in for a reason, and I wasn't going to submit a patch to pull-out
the local buffer manager without clearing it first.
The main area where it seems to get heavy use is during index builds,
and for 'CREATE TABLE AS SELEC
> On Fri, 2002-08-02 at 08:55, Curt Sampson wrote:
> > On Fri, 2 Aug 2002, Marc G. Fournier wrote:
> >
> > > Isn't inheritance kinda one of those things that is required in order to
> > > be consider ourselves ORBDMS, which we do classify our selves as being?
> >
> > Well, it depends on what you
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> Ok. This is what I wanted to hear, but I had assumed someone decided to
> put it in for a reason, and I wasn't going to submit a patch to pull-out
> the local buffer manager without clearing it first.
> The main area where it seems to get heavy use is d
On Thu, 2002-08-01 at 23:30, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > I seem to find this argument a lot on the list here. For some reason,
> > many of the developers are under the impression that even if code is
> > never touched, it has a very high level of effort to keep
Perhaps I'm not remembering correctly, but don't SQL functions still
have an abnormally high cost of execution compared to plpgsql?
Want to try the same thing with a plpgsql function?
On Thu, 2002-08-01 at 18:23, Neil Conway wrote:
> Ok, here are some crude benchmarks to attempt to measure th
Greg Copeland <[EMAIL PROTECTED]> writes:
> On Thu, 2002-08-01 at 23:30, Tom Lane wrote:
>> FWIW, I did not notice any of the core developers making that case.
> I've seen it used a lot.
Perhaps my meaning wasn't clear: I meant that no one who's familiar
with the code base has made that argument
Rod Taylor <[EMAIL PROTECTED]> writes:
> Perhaps I'm not remembering correctly, but don't SQL functions still
> have an abnormally high cost of execution compared to plpgsql?
> Want to try the same thing with a plpgsql function?
Actually, plpgsql is pretty expensive too. The thing to be benchm
On Wed, 2002-07-31 at 22:20, Bruce Momjian wrote:
> I am wondering why we even want to specify the WAL location anywhere
> except as a flag to initdb. If you specify a location at initdb time,
> it creates the /xlog directory, then symlinks it into /data.
>
Does this have any negative implicati
On Fri, Aug 02, 2002 at 03:48:39PM +0400, Yaroslav Dmitriev wrote:
>
> So I am still interested in PostgreSQL's ability to deal with
> multimillon records tables.
[x-posted and Reply-To: to -general; this isn't a development
problem.]
We have tables with multimillion records, and they are fast
On Fri, 2002-08-02 at 10:01, Tom Lane wrote:
>
> Just out of curiosity, though, what does it matter? On re-reading your
> message I think you are dealing with a non problem, or at least the
> wrong problem. Local relations do not need to be checkpointed, because
> by definition they were create
Hi
> And what's the problem with networkcard_products being a separate table
> that shares a key with the products table?
>
> CREATE TABLE products (product_id int, ...)
> CREATE TABLE networkcard_products_data (product_id int, ...)
> CREATE VIEW networkcard_products AS
> SELECT produ
Neil Conway said:
>> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
>
>Until someone takes the time to determine what the performance
>implications of this change will be, I don't think we should
>change this. Given that no one has done any testing, I'm not
>convinced that there's
On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote:
>
> > Of course my humble but thoroughly biased opinion is that libpq++ be
> > marked "legacy."
>
> No doubt, but, if we didn't "push" one interface over another, then it
> would be up to the end-users themselves to decide which o
On Thu, 2002-08-01 at 00:42, Stephen Deasey wrote:
> Neil Conway said:
> >> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> >
> >Until someone takes the time to determine what the performance
> >implications of this change will be, I don't think we should
> >change this. Given tha
> > I am wondering why we even want to specify the WAL location anywhere
> > except as a flag to initdb. If you specify a location at initdb time,
> > it creates the /xlog directory, then symlinks it into /data.
> Does this have any negative implications for Win32 ports?
Sure. the symlinks thing
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> What would happen if a transaction with a local relation commits during
> backup, and there are log entries inserting the catalog tuples into
> pg_class. Should I not apply those on restore? How do I know?
This is certainly a non-problem. You see a WAL
On Fri, 2 Aug 2002, Thomas Lockhart wrote:
> > > I am wondering why we even want to specify the WAL location anywhere
> > > except as a flag to initdb. If you specify a location at initdb time,
> > > it creates the /xlog directory, then symlinks it into /data.
> > Does this have any negative imp
On Fri, 2002-08-02 at 13:50, Richard Tucker wrote:
> pg_copy does not handle "local relations" as you would suspect. To find the
> tables and indexes to backup the backend in processing the "ALTER SYSTEM
> BACKUP" statement reads the pg_class table. Any tables in the process of
> coming into exi
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> The predicate for files we MUST (fuzzy) copy is:
> File exists at start of backup && File exists at end of backup
Right, which seems to me to negate all these claims about needing a
(horribly messy) way to read uncommitted system catalog entries, do
On Fri, 2002-08-02 at 13:46, Thomas Lockhart wrote:
> > > I am wondering why we even want to specify the WAL location anywhere
> > > except as a flag to initdb. If you specify a location at initdb time,
> > > it creates the /xlog directory, then symlinks it into /data.
> > Does this have any nega
Thomas Lockhart wrote:
> ...
> > Perhaps a more relevant question is why are we cluttering the namespace
> > with any such function at all? What's the use case for it? We've
> > gotten along fine without one so far, and I don't really think that we
> > *ought* to be exposing random bits of inter
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps a more relevant question is why are we cluttering the namespace
> > with any such function at all? What's the use case for it?
> It was requested because it is exposed in libpq and people need it to
> generate unique names and stuff like that
On Fri, 2002-08-02 at 16:01, Tom Lane wrote:
> "J. R. Nield" <[EMAIL PROTECTED]> writes:
> > The predicate for files we MUST (fuzzy) copy is:
> > File exists at start of backup && File exists at end of backup
>
> Right, which seems to me to negate all these claims about needing a
> (horribly m
> > The predicate for files we MUST (fuzzy) copy is:
> > File exists at start of backup && File exists at end of backup
>
> Right, which seems to me to negate all these claims about needing a
> (horribly messy) way to read uncommitted system catalog entries, do
> blind reads, etc. What's wron
> > (In particular, I *strongly* object to using the buffer
> manager at all
> > for reading files for backup. That's pretty much
> guaranteed to blow out
> > buffer cache. Use plain OS-level file reads. An OS
> directory search
> > will do fine for finding what you need to read, too.)
>
>
On Fri, 2002-08-02 at 16:59, Mikheev, Vadim wrote:
> You don't need it.
> As long as whole block is saved in log on first after
> checkpoint (you made before backup) change to block.
I thought half the point of PITR was to be able to turn off pre-image
logging so you can trade potential recovery
"J. R. Nield" <[EMAIL PROTECTED]> writes:
>> (In particular, I *strongly* object to using the buffer manager at all
>> for reading files for backup. That's pretty much guaranteed to blow out
>> buffer cache. Use plain OS-level file reads. An OS directory search
>> will do fine for finding what
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> So, we only have to use shared buffer pool for local (but probably
> not for temporary) relations to close this issue, yes? I personally
> don't see any performance issues if we do this.
Hmm. Temporary relations are a whole different story.
It woul
> > So, we only have to use shared buffer pool for local (but probably
> > not for temporary) relations to close this issue, yes? I personally
> > don't see any performance issues if we do this.
>
> Hmm. Temporary relations are a whole different story.
>
> It would be nice if updates on temp re
> > You don't need it.
> > As long as whole block is saved in log on first after
> > checkpoint (you made before backup) change to block.
>
> I thought half the point of PITR was to be able to turn
> off pre-image logging so you can trade potential recovery
Correction - *after*-image.
> time fo
> > How do you get atomic block copies otherwise?
>
> Eh? The kernel does that for you, as long as you're reading the
> same-size blocks that the backends are writing, no?
Good point.
Vadim
---(end of broadcast)---
TIP 2: you can get off all lis
> > > As long as whole block is saved in log on first after
> > > checkpoint (you made before backup) change to block.
> >
> I thought half the point of PITR was to be able to
> turn off pre-image logging so you can trade potential
> recovery time for speed without fear of data-loss.
> Didn't we h
Are you sure this is true for all ports? And if so, why would it be
cheaper for the kernel to do it in its buffer manager, compared to us
doing it in ours? This just seems bogus to rely on. Does anyone know
what POSIX has to say about this?
On Fri, 2002-08-02 at 18:01, Mikheev, Vadim wrote:
> >
I think this happens because you are using cygwin envrionment. Under
cygwin environment a shared object(dll) cannot be built until the
backend bild completes. I heard this theory from a cygwin expert in
Japan. If this is correct, we have to move utils/mb/conversion_procs
to right under src so that
> Are you sure this is true for all ports?
Well, maybe you're right and it's not.
But with "after-image blocks in log after checkpoint"
you really shouldn't worry about block atomicity, right?
And ability to turn blocks logging on/off, as suggested
by Richard, looks as appropriate for everyone, ?
Richard Tucker <[EMAIL PROTECTED]> writes:
> 1) Issue an ALTER SYSTEM BEGIN BACKUP command which turns on atomic write,
> checkpoints the database and disables further checkpoints (so wal files
> won't be reused) until the backup is complete.
> 2) Change ALTER SYSTEM BACKUP DATABASE TO read the d
> So I think what will work then is pg_copy (hot backup) would:
> 1) Issue an ALTER SYSTEM BEGIN BACKUP command which turns on
> atomic write,
> checkpoints the database and disables further checkpoints (so
> wal files
> won't be reused) until the backup is complete.
> 2) Change ALTER SYSTEM BAC
> I really dislike the notion of turning off checkpointing. What if the
> backup process dies or gets stuck (eg, it's waiting for some
> operator to
> change a tape, but the operator has gone to lunch)? IMHO, backup
> systems that depend on breaking the system's normal
> operational behavior
>
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> It should be sufficient to force a checkpoint when you
>> start and when you're done --- altering normal operation in between is
>> a bad design.
> But you have to prevent log files reusing while you copy data files.
No, I don't think so. If you a
> >> It should be sufficient to force a checkpoint when you
> >> start and when you're done --- altering normal operation
> in between is
> >> a bad design.
>
> > But you have to prevent log files reusing while you copy data files.
>
> No, I don't think so. If you are using PITR then you presu
Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> It should be sufficient to force a checkpoint when you
> >> start and when you're done --- altering normal operation in between is
> >> a bad design.
>
> > But you have to prevent log files reusing while you copy data files.
>
>
> > Well, PITR without log archiving could be alternative to
> > pg_dump/pg_restore, but I agreed that it's not the big
> > feature to worry about.
>
> Seems like a pointless "feature" to me. A pg_dump dump serves just
> as well to capture a snapshot --- in fact better, since it's likely
> small
Thomas Lockhart wrote:
> > > I am wondering why we even want to specify the WAL location anywhere
> > > except as a flag to initdb. If you specify a location at initdb time,
> > > it creates the /xlog directory, then symlinks it into /data.
> > Does this have any negative implications for Win32 p
Thomas Lockhart wrote:
> > > With FUNC_MAX_ARGS=16:
> > > (average = 28.6 seconds)
> > > With FUNC_MAX_ARGS=32:
> > > (average = 29.15 seconds)
>
> That is almost a 2 percent cost. Shall we challenge someone to get us
> back 2 percent from somewhere before the 7.3 release? Optimizing a hot
> spot
Tom Lane wrote:
> This would simplify development/maintenance at the cost of a small
> amount of CPU time building the index OID list whenever it wasn't
> already cached. (OTOH ... I'm unsure whether opening an index by OID
> is any faster than opening it by name, but it's certainly plausible tha
...
> I was just wondering why we would deal with environment variables or
> postgresql.conf settings. Just make it an initdb flag, create it in the
> desired location with a symlink in /data and then we don't have to do
> any more work for WAL locations unless people want to move it around
> aft
Thomas Lockhart wrote:
> ...
> > I was just wondering why we would deal with environment variables or
> > postgresql.conf settings. Just make it an initdb flag, create it in the
> > desired location with a symlink in /data and then we don't have to do
> > any more work for WAL locations unless pe
...
> I wasn't terribly concerned because this wasn't a 2% on normal workload
> test, it was a 2% bang on function calls as fast as you can test.
Yeah, good point. But if we can get it back somehow that would be even
better :)
- Thomas
---(end of broadc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't terribly concerned because this wasn't a 2% on normal workload
> test, it was a 2% bang on function calls as fast as you can test.
No, it was a 2% hit on rather slow functions with only one call made
per query issued by the client. This is not
I have been wondering if we should add a web page of a list of
developers working on PostgreSQL who's time is sponsored by companies.
I know myself (SRA), Tom Lane(RH), Neil Conway (RH), and probably many
others sponsor PostgreSQL developement, and I think we should have a way
of recognizing suc
Tom Lane wrote:
> No, it was a 2% hit on rather slow functions with only one call made
> per query issued by the client. This is not much of a stress test.
>
> A more impressive comparison would be
>
> select 2+2+2+2+2+2+ ... (iterate 1 times or so)
>
> and see how much that slows down.
I
94 matches
Mail list logo
