n? If not, can you drop and re-create and confirm
that you get the WARNING? If not, we have problems.
I vote to make this an ERROR in 8.1 - I see little benefit in allowing
this situation to continue. If users do create a FK like this, it just
becomes another performance problem on list...
Best Regar
On Fri, 2005-03-25 at 03:50 -0700, Karim Nassar wrote:
> On Fri, 2005-03-25 at 10:18 +0000, Simon Riggs wrote:
> > > When running with PostgreSQL 7.4 on a dual-CPU Athlon MP2400+ machine
> > > with a gigabyte of RAM, running Debian Linux version 2.6.8.1, we were
> >
On Fri, 2005-03-25 at 10:17 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I vote to make this an ERROR in 8.1 - I see little benefit in allowing
> > this situation to continue.
>
> Other than spec compliance, you mean? SQL99 says
>
>
On Fri, 2005-03-25 at 08:23 -0800, Stephan Szabo wrote:
> On Fri, 25 Mar 2005, Simon Riggs wrote:
>
> > On Fri, 2005-03-25 at 10:17 -0500, Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > I vote to make this an ERROR in 8.1 - I see
On Fri, 2005-03-25 at 13:47 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2005-03-25 at 10:17 -0500, Tom Lane wrote:
> >>> Other than spec compliance, you mean? SQL99 says
> >>>
> >>> ... The declared type of each
On Fri, 2005-03-25 at 16:25 -0500, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 25 Mar 2005, Simon Riggs wrote:
> >> Could it be that because PostgreSQL has a very highly developed sense of
> >> datatype comparison that we might be t
ed out and we should
> go back to recording just the actual stats.
>
> Sound reasonable? Or was I right the first time and suffering brain
> fade today?
Well, I think the original idea had some validity, but clearly
lazy_update_relstats isn't the way to do
;t know what to look at next though.
>
Karim, please...
run the EXPLAIN after doing
SET enable_seqscan = off
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Mon, 2005-03-28 at 09:37 -0700, Karim A Nassar wrote:
> On Mon, 28 Mar 2005, Stephan Szabo wrote:
> > > On Mon, 28 Mar 2005, Simon Riggs wrote:
> > > > run the EXPLAIN after doing
> > > > SET enable_seqscan = off
>
> ...
>
> >
he table, which is too many rows per value to
make an IndexScan an efficient way of deleting rows from the table.
Thats it.
If you have more values when measurement is bigger, the delete will
eventually switch plans (if you reconnect) and use the index. But not
yet.
Th
gt; increasing work_mem for the duration. Hmmm ... or maintenance_work_mem?
> What gets used for FK checks? Simon?
>
In 8.0, maintenance_work_mem is used for index creation, vacuum and
initial check of FK checks at time of creation. Everything else uses
work_mem as
treated just as very-low-selectivity indexes? - they're a very similar
situation in terms of forcing an absolute, not relative, number of rows
returned.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Tue, 2005-03-29 at 05:50 -0800, Stephan Szabo wrote:
> On Tue, 29 Mar 2005, Simon Riggs wrote:
>
> > On Tue, 2005-03-29 at 01:48 -0700, Karim A Nassar wrote:
> > > > Each value has 1/13th of the table, which is too many rows per value to
> > > > make an In
hes the criteria
which means we can use LIMIT 1
If action is CASCADE, SET NULL, SET DEFAULT then
we need to UPDATE or DELETE all rows that match the criteria
which means we musnt use LIMIT and need to use FOR UPDATE
We know that at CONSTRAINT creation time,
On Tue, 2005-03-29 at 10:31 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If action is NO ACTION or RESTRICT then
> > we need to SELECT at most 1 row that matches the criteria
> > which means we can use LIMIT 1
>
> > If action is
On Tue, 2005-03-29 at 09:40 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ...but, I see no way for OidFunctionCall8 to ever return an answer of
> > "always just 1 row, no matter how big the relation"...so tuples_fetched
> > is always pro
On Tue, 2005-03-29 at 12:31 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > That implies to me that LIMIT queries are not considered correctly in
> > the M&L formula and thus we are more likely to calculate a too-high cost
> > for using an inde
upper bound estimate of cardinality of the
cartesian product is feasible AND still low enough to use the index on
Sales.
This is probably going to need information to be captured on multi-
column index selectivity, to ensure that last part.
It is likely that the statistics targets on the dimension
with the switch from one table to
another? That is an important point.
Q: How many data files are there for these relations? Wouldn't be two,
by any chance, when we have 10 million rows in them?
Q: What is the average row length?
About 150-160 bytes?
Thanks,
Best Regards,
On Mon, 2005-04-04 at 15:56 -0400, Christopher Petrilli wrote:
> On Apr 4, 2005 3:46 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > On Mon, 2005-04-04 at 09:48 -0400, Christopher Petrilli wrote:
> > > The point, in the rough middle, is where the program begins insertin
On Mon, 2005-04-04 at 16:18 -0400, Christopher Petrilli wrote:
> On Apr 4, 2005 4:11 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > > I'm very interested in the graphs of elapsed time for COPY 500 rows
> > > > against rows inserted. The simplistic inference
On Mon, 2005-04-04 at 17:03 -0400, Christopher Petrilli wrote:
> On Apr 4, 2005 4:58 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Can you do:
> > select relname from pg_class where relfilenode = 26488271
> > and confirm that the name is the table you&#x
;t unique to PostgreSQL; the explanation developed here
would work equally well for any database system that used tree-based
indexes. Do we still think that MySQL can do this when PostgreSQL
cannot? How?
Do we have performance test results showing the same application load
without the degradation? We
On Tue, 2005-04-05 at 18:55 -0400, Christopher Petrilli wrote:
> On Apr 5, 2005 3:48 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > B-trees aren't unique to PostgreSQL; the explanation developed here
> > would work equally well for any database system that used tree-base
On Tue, 2005-04-05 at 16:05 -0400, Christopher Petrilli wrote:
> On Apr 5, 2005 3:48 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > The indicated fix of course is to increase shared_buffers.
> >
> > Splitting your tables at 4M, not 10M would work even better.
&g
was supported.
> probably can be treated as a range restriction on a.x for this purpose,
> but I'm much less sure that the same is true of
>
> a.x > b.y AND a.x < c.z
I can't think of a query that would use such a construct, and might even
conclude that it was ver
it to shine through. Not
thought about heap/index issues.
It is possible that an XLogWriter process could be used to assist in the
CRC and compression calculations also, an a similar process used to
assist decompression for recovery, in time.
I regret I do not currently have time to pursue further
: 4
> OS: SunOS sun 5.8
> RDBMS: PostgreSQL 8.0
> How to encrease postgresql speed? Why postgres took only 5.0% of CPU time?
When you say restore...what are you actually doing?
An archive recovery?
A reload?
A file-level restore of database?
Best Regards, Simon Riggs
r large, when incorrect
statistics could force scans and sorts to occur when they aren't
actually needed ?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Mon, 2005-04-25 at 11:23 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > My suggested hack for PostgreSQL is to have an option to *not* sample,
> > just to scan the whole table and find n_distinct accurately.
> > ...
> > What price a sing
ion it does seem likely that when taking a
sample, all site visitors clicked more than once during their session,
especially if they include home page, adverts, images etc for each page.
Could it be that we have overlooked this simple explanation and that the
Haas and Stokes equation is actually quite goo
On Mon, 2005-04-25 at 17:10 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2005-04-25 at 11:23 -0400, Tom Lane wrote:
> >> It's not just the scan --- you also have to sort, or something like
> >> that, if you want to count dist
...and this offers the possibility of calculating statistics at load
time, as part of the COPY command
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
initial development is large
and complex. There are many TODO items that have lain untouched for
years, even though adding the feature has been discussed and agreed.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
and my sole intent was
to encourage Alex and other readers to act themselves. If my words seem
arrogant, then I apologise to any and all that think so.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
index scan on a table that is not in clustered sequence.
The more out of sequence the table is, the more memory is required to
avoid doing any repeated I/Os during the scan. Of course, if there are
many users, the available cache may be much reduced.
Best regards, Simon Riggs
--
hese tables are searched.
> While moving to PostgreSQL is it a good idea to move from using
> multiple tables to one table for so many rows?
No. All of the same reasoning applies.
Try to keep each table small enough to fit easily in RAM.
Make sure you specify WITHOUT OIDS on the main dat
and 2 gigs of mem. Right now the sort
> mem is a 4 megs. How much higher could I put that?
>
Please post your server hardware config all in one go. You have more
than 2 CPUs, yes?
Also, mention what bgwriter settings are. You may need to turn those
down a bit.
B
s up somewhere slightly down from the root
of the class hierarchy?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: 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
e too big
to fit in memory, hence the leap in response times.
The workaround is to split the table into smaller pieces.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
would open
the door to the use of very high work_mem values.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that y
Don't use the vacuum_cost_delay in this situation. You might try setting
it to 0 for the analyze_thread only.
Sounds like you could speed things up by splitting everything into two
sets of tables, with writer_thread1 and writer_thread2 etc. That way
your 2 CPUs would be able to independently be ab
On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote:
> On Mon, 2005-07-11 at 07:31, Simon Riggs wrote:
> > The ANALYZE commands hold read locks on the tables you wish to write to.
> > If you slow them down, you merely slow down your write transactions
> > also, and then
On Mon, 2005-07-11 at 15:51 +0100, Simon Riggs wrote:
> On Mon, 2005-07-11 at 09:07 -0400, Ian Westmacott wrote:
> > On Mon, 2005-07-11 at 07:31, Simon Riggs wrote:
> > > The ANALYZE commands hold read locks on the tables you wish to write to.
> > > If you slow them down
e in LWLockAcquire
> and LWLockRelease (20% each vs. 2%).
Is this associated with high context switching also?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose
tion cache on the CPU. It is likely it is
the instruction cache that is too small to fit all of the code required
for your application's workload mix.
Use Intel VTune or similar to show the results you seek.
Best Regards, Simon Riggs
---(end of broadcast)
ver uses real prepared statements instead of faked
> ones. The problem is the new protocol (that the 8.0.2 driver users) has
> a bug where protocol-prepared queries don't get logged properly.
>
> I don't know if it's been fixed...
Yes, there is a fix for t
On Wed, 2005-07-13 at 14:58 -0400, Tom Lane wrote:
> Ian Westmacott <[EMAIL PROTECTED]> writes:
> > On Wed, 2005-07-13 at 11:55, Simon Riggs wrote:
> >> On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
> >>> It appears not to matter whether it is one
y. If a row is not found,
you know that it has ftindex=true. That way, you'll never have row
versions building up in the main table, which you'll still get even if
you VACUUM.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1:
On Thu, 2005-07-14 at 14:29 +0800, Christopher Kings-Lynne wrote:
> Try turning on query logging and using the 'pqa' utility on pgfoundry.org.
Have you got that to work for 8 ?
pqa 1.5 doesn't even work with its own test file.
Best Regards, Simon Riggs
rd perf reports also.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
restart.
If you have gallons of GB, you will probably by looking to make use of
such tables.
You can use such tables for the style of ETL known as ELT, but that is
not the only use.
Best Regards, Simon Riggs
---(end of broadcast)---
ans are made for each child table. I don't
think the situation you observe occurs as a result of query planning.
Do your child tables have indexes on them? Indexes are not inherited
onto child tables, so it is possible that there is no index for the
planner to elect to use.
Best Regards, Sim
imple transform looks good. I'm
not sure it's a very common query type though...
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ould have only one join for each new keyword.
> Can whe do something on the postgresql configuration to avoid this ?
> Can whe force the planner to use a hash join as it does for the first
> joins ?
Not required, IMHO.
Best Regards, Simon Riggs
---(end of br
would use to reformulate the query that way, so no luck that way either.
If you don't want to do this in a view, calculate the values for all
players at once and store the values in a summary table for when you
need them.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
ed down clauses,
which also references a more constant base view?
Is a 51ms query really such a problem for you?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
c
g cached in memory immediately after the same select
> which took 390 ms on a quiet system.
If the current value is used so often, use two tables - one with a
current view only of the row maintained using UPDATE. Different
performance issues maybe, but at least not correlated subquery ones.
Best
r the tapesort. That way the
memory can be freed for use by other users or the OS while the tapesort
proceeds (which is usually quite a while...).
Feedback, please.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our
AtDate desc
> > > LIMIT 1);
I think you should try:
select distinct on (PlayerID) PlayerID,AtDate from Player a
where PlayerID='0' order by PlayerId, AtDate Desc;
Does that work for you?
Best Regards, Simon Riggs
---(end of broadcast)---
On Fri, 2005-09-23 at 10:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If not, I would propose that when we move from qsort to tapesort mode we
> > free the larger work_mem setting (if one exists) and allocate only a
> > lower, though st
ong with my earlier tests.
Best Regards, Simon Riggs
---(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
On Fri, 2005-09-23 at 11:31 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Since we know the predicted size of the sort set prior to starting the
> > sort node, could we not use that information to allocate memory
> > appropriately? i.e. if sort s
on't wish to be drawn further on solutions at this stage
but I am collecting performance data, so any test results are most
welcome.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
7;m happy to code this up if
you choose not to, once I've done my other immediate chores.
That just leaves these issues for a later time:
- CPU and I/O interleaving
- CPU cost of abstract data type comparison operator invocation
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
EINDEX or dump/restore should be identical.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ll allow XPath and
friends.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
7;t seem worth doing another RC just for that.
Will this be documented in the release notes? If we put unimplemented
features in TODO, where do we list things we regard as bugs?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
Please be aware that publishing Oracle performance results is against
the terms of their licence and we seek to be both fair and legitimate,
especially within this public discussion forum.
Best Regards, Simon Riggs
---(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
ced software) and a note that this does not imply the
latest releases are not yet production (in comparison to MySQL or Sybase
who have been in beta for a very long time).
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: if posting/r
back down again, try the test, then reset and try the test.
If that is a repeatable way of recreating one manifestation of the
problem then we will be further ahead than we are now.
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: H
egards, Simon Riggs
---(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
t; scan base_1,base_2. Result: you'll scan all child tables of base.
>
> I think the planner will occasionally evaluate constants before
> planning, but I don't think it will ever execute a subquery and then
> re-plan the outer query based on those results. Of course, someon
hat big of an improvement for multiple tables given
> that all the data is still stored on the same filesystem?
You could store partitions in separate tablespaces/filesystems.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
rious aspects of this technique, yet at least other 3 vendors
manage to achieve this. So far I've not dug too deeply, but I understand
the optimizations we'd need to perform in PostgreSQL to do this.]
Best Regards, Simon Riggs
---(end of broadcast)---
sking them to send their
command strings, all of the time, deferred or not will always be more
wasteful. Plus if you forgot to turn on stats_command_string before
execution, then you've no way of knowing anyhow.
Best Regards, Simon Riggs
---(end of broadcast)
analysis would be much
appreciated.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
aguilar-2005-4.pdf
>
>
> They seem to be describing a more subtle method making use of join
> indexes and bitmapped indexes.
Which is the option (2) I described.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Sat, 2005-12-17 at 13:13 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2005-12-16 at 23:28 -0500, Bruce Momjian wrote:
> >> How are star joins different from what we do now?
>
> > Methods:
> > 1. join all N small tables tog
ble joins. And we have some clues as to how we might
do that.
Best Regards, Simon Riggs
---(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
describing
> the "star transformation" - upon re-reading, I see that yes, it's more
> or less a description of the O'Neil Graefe method.
Papers look interesting; I'd not seen them. My knowledge of this is
mostly practical.
O'Neil and Graefe seem to b
7;t got a working copy of DB2 in front of me to test.
True, not all copies work :-)
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
at optimizer, whatever we say in its defence. I don't want to
leave this alone, but I don't want to spend a month fixing it either.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
On Fri, 2006-12-15 at 11:50 +0100, Martijn van Oosterhout wrote:
> On Fri, Dec 15, 2006 at 10:28:08AM +0000, Simon Riggs wrote:
> > Until we work out a better solution we can fix this in two ways:
> >
> > 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATIS
On Fri, 2006-12-15 at 10:57 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
> >> Until we work out a better solution we can fix this in two ways:
> >>
> >> 1. EXPLAIN AN
og/archive_status directory? Thanks.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
re were hundreds of files, but these
> disappeared after Postgres performed the automatic recovery.
What were you doing before the server crashed?
Did you previously have checkpoint_segments set higher? When/how was it
reduced?
--
Simon Riggs
EnterpriseDB
%s path: %s" so we
can see where the file was created (there is another todo about creating
temp files in different locations)
- add a trace point also for those who don't want to enable a parameter,
described here
http://www.postgresql.org/docs/8.2/static/dynamic-trace.html
e
for the
CheckpointStartLock. That helps the checkpoint, but it harms performance
of other transactions waiting to commit, so I let that idea go.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
ease levels?
That will give you a better feel for the spread of likely values.
The distribution of rows with those values also makes a difference to
the results. ANALYZE assumes that all values are randomly distributed
within the table, so if the values are clumped together for whatever
reason the ndistinct calc is less likely to take that into account.
The larger sample size gained by increasing stats target does make a
difference.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ldn't be affected in the same way, theoretically, if you
> have constraint_exclusion enabled.
Selects can incur parsing overhead if there are a large number of
partitions. That will be proportional to the number of partitions, at
present.
--
Simon Riggs
EnterpriseDB htt
On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
> On 1/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> If you are doing date range partitioning it should be fairly
> simple to
> load data into the latest table directly. That was the way I
&g
om hackers?
It's not clear to me how this fix will alter the INSERT issue Kim
mentions. Are those issues connected? Or are you thinking that handling
stats in a tight loop is slowing down other aspects of the system?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Thu, 2007-01-11 at 16:11 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > It's not clear to me how this fix will alter the INSERT issue Kim
> > mentions.
>
> I didn't say that it would; we have no information on the INSERT is
of targets because that would be quicker than re-scanning
a temp table repeatedly just to extract a few rows each time.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you se
functioning for some reason.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
elect from the persons table it is showing
> the records from its inherited tables as well. Can anybody tell me
> what might be the problem here?
http://www.postgresql.org/docs/8.2/static/ddl-inherit.html
answers your questions, I believe.
--
Simon Riggs
57307.394 ms
All your time is in the sort, not in the SeqScan.
Increase your work_mem.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
t will
also help us support the optimiser when it is acting in extreme
conditions that are not sensibly reproducible in reality by hackers. It
will also provide us with what-if capability for system expansion.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
On Mon, 2007-04-09 at 16:05 -0400, Carlos Moreno wrote:
> 2) What would be the real implications of doing that?
Many people ask, hence why a whole chapter of the manual is devoted to
this important topic.
http://developer.postgresql.org/pgdocs/postgres/wal.html
--
Simon Ri
1 - 100 of 392 matches
Mail list logo
