On Thu, Nov 13, 2003 at 04:37:03PM -0500, Andrew Sullivan wrote:
> Actually, this one's on an internal box, and I think 1.5 is too low
> -- it's really just a pair of mirrored SCSI disks on a PCI controller
> in this case. That does the trick, though, so maybe I'm just being
> too conservantive.
On Thu, Nov 13, 2003 at 03:19:08PM -0500, Tom Lane wrote:
> because the system can usually do all right on range estimates if you've
> let it run an ANALYZE with enough histogram bins. Could we see the
> pg_stats row for transaction_date?
Do you want the whole thing? I left out the really verbos
Daniel Manley <[EMAIL PROTECTED]> writes:
> The product_id alone gives a difference of a millions rows from estimate
> to actual, vs. the factor of 2 from the transaction_date.
You should be thinking in terms of ratios, not absolute difference.
The rows estimate for product_id doesn't look too ba
Hi, I'm the lead developer on the project this concerns (forgive my
newbiness on this list).
We tried a couple of scenarios with effective_cache_size=6,
cpu_index_tuple_cost=0.0001 and random_page_cost=2 with no change in the
plan.
explain analyse select * from tablename where transaction_
Folks,
How would I calculate storage space/required ram on a 50-digit NUMERIC?
And the docs state that NUMERIC is slow. Is this just slow for calculations
(due to the conversion to float & back) or slow for index lookups as well?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---
Tom Lane wrote:
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
NOT EXISTS is taking almost double time than NOT IN .
I know IN has been optimised in 7.4 but is anything
wrong with the NOT EXISTS?
That's the expected behavior in 7.4. EXISTS in the style you are using
i
> In this particular case the inaccurate estimate doesn't matter too much,
> I think, although it might be encouraging the system to select hash
> aggregation since it thinks the hashtable will be pretty small. If the
> estimate were getting used to plan higher-up plan steps then it could
> be a b
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> The statistics on transaction_date and product_id are set to 1000.
> Everything is all analysed nicely. But I'm getting a poor plan,
> because of an estimate that the number of rows to be returned is
> about double how many actually are:
> explain an
"Arthur Ward" <[EMAIL PROTECTED]> writes:
> EXPLAIN ANALYZE SELECT id FROM
> (SELECT id, commodity FROM commodities WHERE commodity IS NOT NULL
>UNION
> SELECT id, fak FROM commodities WHERE fak IS NOT NULL
> ) all_commodities GROUP BY id;
>
On 7.4 RC2, I'm seeing a case where the query planner estimates are way
out of line after grouping the result of a union. I've tried adjusting the
statistics targets up to 200, and it made no difference in the planner's
estimates. The point of the full query this came from is that it also has
an ag
Hi all,
I've one here that I cannot fathom. Any suggestions?
We have a table, call it tablename, where we're selecting by a range
of dates and an identifier. (This is redacted, obviously):
\d tablename
Column | Type | Modifiers
On Thu, 2003-11-13 at 12:00, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Does the not exist query produce worse results in 7.4 than it did in
> > 7.3?
>
> EXISTS should work the same as before.
>
right. the original poster is asking if there is "something wrong with
exist" bas
Robert Treat <[EMAIL PROTECTED]> writes:
> Does the not exist query produce worse results in 7.4 than it did in
> 7.3?
EXISTS should work the same as before.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked
It is believed that the IN optimization can lead to faster IN times than
EXIST times on some queries, the extent of which is still a bit of an
unknown. (Incidentally is there an FAQ item on this that needs
updating?)
Does the not exist query produce worse results in 7.4 than it did in
7.3?
Robert
Robert Treat wrote:
It is believed that the IN optimization can lead to faster IN times than
EXIST times on some queries, the extent of which is still a bit of an
unknown. (Incidentally is there an FAQ item on this that needs
updating?)
Thanks every one for clarifying. Its really a nice
Rajesh Kumar Mallah wrote:
>
> Hi,
>
> NOT EXISTS is taking almost double time than NOT IN .
> I know IN has been optimised in 7.4 but is anything
> wrong with the NOT EXISTS?
>
> I have vaccumed , analyze and run the query many times
> still not in is faster than exists :>
Seems fine. In 7.4
On Wed, 2003-11-12 at 09:28, Jeff wrote:
> On Tue, 11 Nov 2003 21:13:19 -0500
> "Chris Field" <[EMAIL PROTECTED]> wrote:
>
> > we are looking at Xeon, We are currently running it on a quad sun v880
> > compiled to be 64bit and have been getting dreadful performance. I
> > don't think we really ha
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> NOT EXISTS is taking almost double time than NOT IN .
> I know IN has been optimised in 7.4 but is anything
> wrong with the NOT EXISTS?
That's the expected behavior in 7.4. EXISTS in the style you are using
it effectively forces a nestloop-with-
> > Most clients will be interested in say the last 7 days worth of data?
> > Great.. Start out with 4GB ram on a good Dual CPU -- Opterons seem to
> > work quite well -- and make sure the motherboard can hold double that in
> > memory for an upgrade sometime next year when you've become popular.
Hi,
NOT EXISTS is taking almost double time than NOT IN .
I know IN has been optimised in 7.4 but is anything
wrong with the NOT EXISTS?
I have vaccumed , analyze and run the query many times
still not in is faster than exists :>
Regds
Mallah.
NOT IN PLAN
tradein_clients=# explain analyze S
20 matches
Mail list logo
