might also consider the ratio idx_tup_read::float8 / idx_scan
to see which indexes access a lot of rows per scan.
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
On Mon, Feb 11, 2008 at 05:37:51PM -0700, Michael Fuhr wrote:
> On Mon, Feb 11, 2008 at 04:58:35PM -0700, fabrix peñuelas wrote:
> > If ssl is enable in postgresql decreanse the performance of the database?
> > How much?
>
> The performance impact of an encrypted conn
ce the impact of an encrypted
connection vs. a non-encrypted connection. The most reliable way
to assess the impact would be to run representative queries over
your data and measure the difference yourself.
--
Michael Fuhr
---(end of broadcast)---
mmend disabling sequential scans permanently but doing
so can be useful when investigating why the planner thinks one plan
will be faster than another.
What are your settings for random_page_cost, effective_cache_size,
work_mem, and shared_buffers? If you're using the default
random_page_cost
iew, the join is performed even if your query doesn't return any
> columns from the outer relation. Also, if the calculation contains
> immutable functions, it's not skipped.
Don't you mean "if the calculation contains VOLATILE functions,
it's not skipped"?
--
default_statistics_target.
http://www.postgresql.org/docs/8.2/interactive/sql-altertable.html
http://www.postgresql.org/docs/8.2/interactive/runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
)
order by n1.nspname,
c1.relname,
a1.attname;
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
-1. Negative attstattarget values mean to use the system
default, which you can see with:
SHOW default_statistics_target;
How exactly are you determining that no statistics are showing up
for this table? Are you running a query like the following?
SELECT *
FROM pg_stats
WHERE schemaname =
r this table? Is there any chance that
somebody set all of the columns' statistics targets to zero?
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ned empirically? How much benefit are they
providing and how did you measure that?
enable_mergejoin = off
geqo = off
I've occasionally had to tweak planner settings but I prefer to do
so for specific queries instead of changing them server-wide.
--
Michael Fuhr
-
I can set the compression settings using the "ALTER TABLE
> ALTER SET STORAGE" syntax, but is there a way I can see what this
> value is currently set to?
You could query pg_attribute.attstorage:
http://www.postgresql.org/docs/8.2/interactive/catalog-pg-attribute.html
--
Michae
STATISTICS 100;
ANALYZE event;
You can set the statistics target as high as 1000 to get more
accurate results at the cost of longer ANALYZE times.
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Fri, Mar 30, 2007 at 04:46:11AM -0600, Michael Fuhr wrote:
> Have you tried increasing the statistics target on l_pvcp.value?
> I ran your queries against canned data in 8.2.3 and better statistics
> resulted in more accurate row count estimates for this and other
> parts of the pl
rget on l_pvcp.value?
I ran your queries against canned data in 8.2.3 and better statistics
resulted in more accurate row count estimates for this and other
parts of the plan. I don't recall if estimates for non-leading-character
matches in earlier versions can benefit from better statistics.
n checklist such
as this one:
http://www.powerpostgresql.com/PerfList
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
, inserts, updates, and
deletes in SQL Server and about the implications on ACID of locking
hints such as NOLOCK. Then consider how MVCC handles concurrency
without blocking or the need for dirty reads.
--
Michael Fuhr
---(end of broadcast)---
TIP 3:
On Thu, Mar 15, 2007 at 01:58:47PM +0600, Alexey Romanchuk wrote:
> is it possible to determine dead tuples size for table?
See contrib/pgstattuple.
--
Michael Fuhr
---(end of broadcast)---
TIP 5: don't forget to increase your free s
ld you post the
query and the complete output of EXPLAIN ANALYZE (preferably without
wrapping) for both versions?
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ndex? Is there a specific
index you want to ignore or do you want the planner to ignore all
indexes? What problem are you trying to solve?
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.po
and deletes? All of the above?
Have you used VACUUM VERBOSE to see how much work each VACUUM is doing?
Is it possible that 8.1 was built with --enable-cassert and 8.0
wasn't? What does "SHOW debug_assertions" show on each server?
--
Michael Fuhr
---(end of b
ocedure before doing it for real.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
possibly
because ANALYZE or VACUUM ANALYZE hasn't been run since the data
was loaded. Try running ANALYZE in 8.1 and post the new plans if
that doesn't help.
--
Michael Fuhr
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
. The problem might be with DNS queries for (IPv6)
records prior to queries for A (IPv4) records; see this thread from
almost a year ago:
http://archives.postgresql.org/pgsql-general/2005-08/msg00216.php
--
Michael Fuhr
---(end of broadcast)---
ws locking a shmem segment in RAM?
The Solaris 9 shmctl manpage mentions this token:
SHM_LOCK
Lock the shared memory segment specified by shmid in
memory. This command can be executed only by a process
that has an effective user ID equal to super-user.
--
Michael Fuhr
-
ANALYZE for the fast system and EXPLAIN (without ANALYZE) for the
slow one.
As someone else asked, are you running ANALYZE regularly? What
about VACUUM?
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
utomatically each time a certain user
> connects (not necessarily using psql)?
Beware that setting priorities can have unintended, adverse effects.
Use a search engine to find information about "priority inversion"
before deciding that query priorities are a good idea.
--
Michael Fuh
her tables have
foreign key references to this table? What non-default settings
do you have in postgresql.conf? What version of PostgreSQL are you
running and on what platform? How busy is the system? What's the
output of "EXPLAIN UPDATE mytable ..."?
--
Michael Fuhr
-
n I tend to stay away from them...
8.2 will support NULL array elements.
http://archives.postgresql.org/pgsql-committers/2005-11/msg00385.php
http://developer.postgresql.org/docs/postgres/arrays.html
test=> SELECT '{1,2,NULL,3,4}'::integer[];
int4
--------
{
but the rest of the query can be straight out of
the SQL and OGC standards.
[1] http://www.opengeospatial.org/docs/99-049.pdf
[2] http://www.postgis.org/
[3] http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html
[4] http://www.oracle.com/technology/products/spatial/index.htm
test results:
http://archives.postgresql.org/pgsql-performance/2005-12/msg00307.php
Your results may vary. If you see substantially different results
then please post the particulars.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you search
querying? Might you be hitting geqo_threshold
(default 12)? If so then the following thread might be helpful:
http://archives.postgresql.org/pgsql-performance/2006-01/msg00132.php
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below
mprovements is making the difference.
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[Please copy the mailing list on replies.]
On Mon, Mar 06, 2006 at 09:38:20PM +0100, Joost Kraaijeveld wrote:
> Michael Fuhr wrote:
> > Have you tweaked postgresql.conf at all? If so, what non-default
> > settings are you using?
>
> Yes, I have tweaked t
On Mon, Mar 06, 2006 at 07:46:05PM +0100, Joost Kraaijeveld wrote:
> Michael Fuhr wrote:
> > What's your setting?
>
> Default.
Have you tweaked postgresql.conf at all? If so, what non-default
settings are you using?
> > Are your test results more consistent
>
it
coincidence that the "long time" between fast results is about the
same? What's your setting? Are your test results more consistent
if you execute CHECKPOINT between them?
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if post
xample:
CREATE FUNCTION fooquery(qval text) RETURNS SETOF foo AS $$
DECLARE
rowfoo%ROWTYPE;
query text;
BEGIN
query := 'SELECT * FROM foo WHERE val = ' || quote_literal(qval);
FOR row IN EXECUTE query LOOP
RETURN NEXT row;
END LOOP;
RETURN;
END;
he first way (parameterized)
then the EXPLAIN ANALYZE output would have shown the parameters as
$1, $2, $3, etc., which it didn't.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
, including the
numbered parameters ($1, $2, etc.). To execute the query do this:
EXPLAIN ANALYZE EXECUTE stmt (...);
Where "..." is the same parameter list you'd pass to the function
(the same values you used in the direct query).
If you need to re-prepare the query then run "DE
un VACUUM ANALYZE on all the tables, then run
the query again with EXPLAIN ANALYZE?
--
Michael Fuhr
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Tue, Jan 31, 2006 at 07:29:51PM -0800, Joshua D. Drake wrote:
> > Any ideas?
>
> What does explain analyze say?
Also, have the tables been vacuumed and analyzed?
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
IN ANALYZE DELETE FROM foo WHERE id = 1;
QUERY PLAN
--
Index Scan using foo_pkey on foo (cost=0.00..3.92 rows=1 width=6) (actual
time=0.124.
ng more
tables than that? In another recent thread varying plans were
attributed to exceeding geqo_threshold:
http://archives.postgresql.org/pgsql-performance/2006-01/msg00132.php
Does your situation look similar?
--
Michael Fuhr
---(end of broadcast)-
On Tue, Jan 17, 2006 at 09:04:53AM +, Marcos wrote:
> I already read the documentation for to use the SPI_PREPARE and
> SPI_EXEC... but sincerely I don't understand how I will use this
> resource in my statements.
What statements? What problem are you trying to solve?
--
ERT.
One complication is how to handle rules that run as part of the
insert.
http://www.postgresql.org/docs/faqs.TODO.html
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.
way to suppress this notice when I create tables in a
> >script?
>
> Set[1] your log_min_messages to WARNING or higher[2].
Or client_min_messages, depending on where you don't want to see
the notice.
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ity checks would have to do sequential
scans on the referring table (districts). Indeed, performance
problems for exactly this reason occasionally come up in the mailing
lists.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
back and see what the
> number is for that column? I want to be able to tell which columns I've
> changed the statistics on, and which ones I haven't.
pg_attribute.attstattarget
http://www.postgresql.org/docs/8.1/interactive/catalog-pg-attribute.html
--
Michael
orrection.
http://archives.postgresql.org/pgsql-performance/2006-01/msg00104.php
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Wed, Jan 11, 2006 at 12:56:55AM -0700, Michael Fuhr wrote:
> WHERE ...
> AND doy >= EXTRACT(doy FROM now() - '24 hour'::interval)
> AND doy <= EXTRACT(doy FROM now())
To work on 1 Jan this should be more like
WHERE ...
AND (doy = EXTRACT(doy FROM now()
check for the year, or unless you want to match
more than one year.
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
qscan disabled? That'll show
whether an index or bitmap scan would be faster. And have you
verified that the join condition is correct? Should the query be
returning over a million rows?
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
your configuration settings the same in both versions? You
mentioned increasing work_mem, but what about others like
effective_cache_size, random_page_cost, and shared_buffers?
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you che
On Thu, Dec 22, 2005 at 02:08:23AM +0100, Steinar H. Gunderson wrote:
> On Wed, Dec 21, 2005 at 03:10:28PM -0700, Michael Fuhr wrote:
> >> That's funny, my biggest problems with PL/PgSQL have been (among others)
> >> exactly with large result sets...
> > Out of curi
On Wed, Dec 21, 2005 at 10:38:10PM +0100, Steinar H. Gunderson wrote:
> On Wed, Dec 21, 2005 at 02:24:42PM -0700, Michael Fuhr wrote:
> > The difference is clear only in specific cases; just because you
> > saw a 10x increase in some cases doesn't mean you can expect that
>
ng what problem is to be solved it's near
impossible to recommend an appropriate tool.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
-- workaround 2: quite ugly but seems to work (at least for this
> -- one test case):
> # explain analyze
> select idopont from
> (select idopont from muvelet_vonalkod
>where muvelet=6859 order by idopont) foo
> order by idopont limit 1;
Another worka
on the referring columns? Does this table or
any referring table have triggers? Also, are you regularly vacuuming
and analyzing your tables? Have you examined pg_locks to see if
an unacquired lock might be slowing things down?
--
Michael Fuhr
---(end of broadcast)--
amount of time had expired, and then continue processing the query?
That way admins could avoid the overhead of posting messages for
short-lived queries that nobody's likely to see in pg_stat_activity
anyway.
--
Michael Fuhr
---(end of broadcast)-
8
stats_command_string = on
stats_block_level = on
stats_row_level = on
time: 2:53.76
[Wanders off, swearing that he ran these tests before and saw higher
penalties for block- and row-level statistics.]
--
Michael Fuhr
---(end of broadcast)---
TIP 9
On Mon, Dec 12, 2005 at 10:23:42AM -0300, Alvaro Herrera wrote:
> Michael Fuhr wrote:
> > The cost depends on your usage patterns. I did tests with one of
> > my applications and saw no significant performance difference for
> > simple selects, but a series of insert/update/
t; the hardest if you are doing 1 row at a time operations over a
> persistent connection.
That's basically how the application I tested works: it receives
data from a stream and performs whatever insert/update/delete
statements are necessary to update the database for each chunk of
dat
ce for
simple selects, but a series of insert/update/delete operations ran
about 30% slower when block- and row-level statistics were enabled
versus when the statistics collector was disabled.
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In ve
cl,
PL/Python, etc. There's even a PL/sh:
http://pgfoundry.org/projects/plsh/
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
ferring
to how I wrote two sets of assignments and RETURN NEXT statements,
you don't have to do it that way: you can use a loop, just as you
would with any other set-returning function.
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
t works.
Did you try it? If you did and it didn't work then please post
exactly what you tried and explain what happened and how that
differed from what you'd like.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our lis
N NEXT;
y := y + 1;
z := z + 1;
RETURN NEXT;
END;
$$ LANGUAGE plpgsql IMMUTABLE STRICT;
SELECT * FROM fooset(1, 2);
y | z
+
20 | 10
21 | 11
(2 rows)
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched ou
no effect at all. I tried values clear down to 1
> millisecond, but the server never timed out for any query.
Did you use "SHOW statement_timeout" to see if the value was set
to what you wanted? Are you sure you edited the right file? As a
database superuser execute "SHOW conf
BI on a per-client basis,
> and that works.
You probably shouldn't set statement_timeout on a global basis
anyway, but did you reload the server after you made the change?
Setting statement_timeout in postgresql.conf and then reloading the
server works here in 8.0.4.
--
Michael Fuhr
--
alled, presumably because it can't do so until
the low-level code returns control to Perl.
Is there a reason you're using alarm() in the client instead of
setting statement_timeout on the server?
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
rsion 8.0.2.
I couldn't duplicate this in 8.0.4; I don't know if anything's
changed since 8.0.2 that would affect the query plan. Could you
post the EXPLAIN ANALYZE output? It might also be useful to see
the output with enable_seqscan disabled.
Have the tables been vacuumed and analyz
On Sat, Oct 29, 2005 at 09:49:47AM -0500, Bruno Wolff III wrote:
> On Sat, Oct 29, 2005 at 08:24:32 -0600, Michael Fuhr <[EMAIL PROTECTED]>
> wrote:
> > My tests suggest that a lookup on the referring key is done only
> > if the referenced key is changed. Here's an
ight explain at least some of the performance improvement.
Maybe one of the developers will comment.
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
n you use
COPY, which is much more efficient for bulk loads?
http://www.postgresql.org/docs/8.0/interactive/populate.html
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choo
projects/pgbuffercache/
Note that pg_buffercache shows only pages in PostgreSQL's buffer
cache; it doesn't show your operating system's cache.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archive
pecify whether the data is in
text format or binary. See the libpq documentation for details.
--
Michael Fuhr
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ta in binary, not by automatically converting
to and from text.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
s (this should
be done when nobody else is querying the table so the statistics
represent only what you did).
You can avoid cached plans by using EXECUTE. You'll have to run
tests to see whether the potential gain is worth the overhead.
--
Michael Fuhr
---(end
em; I expect he'll be committing
a fix shortly.
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get t
-> Seq Scan on content c (cost=0.00..1.01 rows=1 width=8)
(actual time=0.025..0.033 rows=1 loops=1)
-> Index Scan using supplier_pkey on supplier s
(cost=0.00..3.01 rows=1 width=4) (actual time=0.046..0.053 rows=1 loops=1)
Index Cond: ("
On Sat, Sep 10, 2005 at 01:03:03AM -0300, Marc G. Fournier wrote:
> On Fri, 9 Sep 2005, Michael Fuhr wrote:
> >INSERT INTO test_check SELECT 1 FROM generate_series(1, 10);
> >INSERT 0 10
> >Time: 3492.344 ms
> >
> >INSERT INTO test_fk SELECT 1 FROM genera
LECT 1 FROM generate_series(1, 10);
INSERT 0 10
Time: 3492.344 ms
INSERT INTO test_fk SELECT 1 FROM generate_series(1, 10);
INSERT 0 100000
Time: 23578.853 ms
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
dom
records into a table and ran the above query.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
quot;EXPLAIN
ANALYZE DELETE ..."? Do you vacuum and analyze the tables regularly?
What version of PostgreSQL are you using?
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
e_middle could use it, making the indexes
on only those columns superfluous. Or am I missing something?
--
Michael Fuhr
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
?
Various tuning guides give advice on how to set the above and other
configuration variables. Here's one such guide:
http://www.powerpostgresql.com/PerfList/
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ne have? If you have enough
memory then raising those variables should result in better plans;
you might also want to experiment with random_page_cost. Be careful
not to set work_mem/sort_mem too high, though. See "Run-time
Configuration" in the "Server Run-time
TO off;
EXPLAIN ANALYZE SELECT ...;
SET enable_seqscan TO off;
SET enable_indexscan TO on;
EXPLAIN ANALYZE SELECT ...;
You might also experiment with planner variables like effective_cache_size
and random_page_cost to see how changing them affects the query
plan. However, be careful of tuning
.postgresql.org/docs/postgres/release.html#RELEASE-8-1
You could probably find more detailed discussion in the pgsql-hackers
archives.
--
Michael Fuhr
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
MIN and MAX
queries.
http://archives.postgresql.org/pgsql-committers/2005-04/msg00163.php
http://archives.postgresql.org/pgsql-committers/2005-04/msg00168.php
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
(this will be improved in 8.1).
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ection_registry_id = 40105) AND (obj1 = 73582))
Total runtime: 0.495 ms
(7 rows)
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so tha
s you show are taking fractions of a
millisecond; the communications overhead of executing two queries
might make that technique significantly slower than just the server
execution time that EXPLAIN ANALYZE shows.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
-
tication" in the documentation:
http://www.postgresql.org/docs/8.0/static/client-authentication.html
If you're trying to do something else then please elaborate, as
it's not clear what you mean by "I want to ALTER that user to exclude
the password."
--
WHERE attstattarget > 0;
See the "System Catalogs" chapter in the documentation for more
information.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 8: explain analyze is your friend
dead tuples, then how can we solve it?
If the function deletes all records from the temporary table then
you could use TRUNCATE instead of DELETE. Otherwise you could
VACUUM the table between calls to the function (you can't run VACUUM
inside a function).
--
Michael Fuhr
http://ww
rom the table on each call, leaving a lot of dead tuples?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
umed and analyzed your tables? Could you post the
EXPLAIN ANALYZE output of a query, once with enable_seqscan turned
on and once with it turned off?
See also "Operator Classes" in the "Indexes" chapter of the
documentation:
http://www.postgresql.org/docs/8.0/static/indexes-o
might not be following this thread.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote:
> On 06/27/2005 06:33:03 PM, Michael Fuhr wrote:
>
> >See timeofday().
>
> That only gives you the time at the start of the transaction,
> so you get no indication of how long anything in the
> transaction
See timeofday().
http://www.postgresql.org/docs/8.0/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
1 - 100 of 130 matches
Mail list logo
