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
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
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
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
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 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
...
> 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
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 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
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
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
> 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(
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
> > 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
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.
>
>
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,
> >> 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
"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
> 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
>
> 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
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
> 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, ?
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? 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:
> >
> > > 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
> > 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
> > 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
> > 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
"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
"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
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
> > (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.)
>
>
> > 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
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
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
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
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
"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: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
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
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
"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, 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
> > 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
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
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
> 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 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 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
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
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
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
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
> "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
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
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
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
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
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
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
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, 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, 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
-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 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
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
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
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
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
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
"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 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
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
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
> >
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
Just making sure that I haven't screwed up anything plugging in amavis ...
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
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
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
* 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
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
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 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 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 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
> 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 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.
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 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
> 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
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,
> > 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
> 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/
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
94 matches
Mail list logo
