Mark Cave-Ayland wrote:
> BTW you mention both EnterpriseDB PostgreSQL 8.3 beta and just
> PostgreSQL 8.3 beta in the text above. Both of these are different -
> which one are you actually using?
No they're not. EnterpriseDB Postgres ships entirely standard binaries -
in fact, the Windows build us
Robert,
On Wed, 2007-12-05 at 15:07 -0500, Robert Treat wrote:
> If the whole performance of your system depends upon indexed access, then
> maybe you need a database that gives you a way to force index access at the
> query level?
That sounds like a request for hints, which is OT here, ISTM.
On Thu, Dec 06, 2007 at 09:38:16AM +, Simon Riggs wrote:
The issue is that if somebody issues a "large query" then it will be a
problem whichever plan the query takes. Forcing index scans can make a
plan more expensive than a seq scan in many cases.
OTOH, the planner can really screw up que
Michael Stone <[EMAIL PROTECTED]> writes:
> OTOH, the planner can really screw up queries on really large databases.
> IIRC, the planner can use things like unique constraints to get some
> idea, e.g., of how many rows will result from a join. Unfortunately,
> the planner can't apply those techn
On Thu, 6 Dec 2007, Tom Lane wrote:
> Indeed, and if you've got examples where it's that far off, you should
> report them.
Oo, oo, I have one!
So, this query bit us a while back. We had two tables being joined
together in a query by a key column. The key column was an integer, and
for the first
Matthew <[EMAIL PROTECTED]> writes:
> ... For this query, Postgres would perform a nested loop,
> iterating over all rows in the small table, and doing a hundred index
> lookups in the big table. This completed very quickly. However, adding the
> LIMIT meant that suddenly a merge join was very attr
Matthew <[EMAIL PROTECTED]> writes:
> On Thu, 6 Dec 2007, Tom Lane wrote:
>> Hmm. IIRC, there are smarts in there about whether a mergejoin can
>> terminate early because of disparate ranges of the two join variables.
> Very cool. Would that be a planner cost estimate fix (so it avoids the
> merg
On Thu, 6 Dec 2007, Tom Lane wrote:
> Matthew <[EMAIL PROTECTED]> writes:
> > ... For this query, Postgres would perform a nested loop,
> > iterating over all rows in the small table, and doing a hundred index
> > lookups in the big table. This completed very quickly. However, adding the
> > LIMIT
On Thu, Dec 06, 2007 at 11:13:18AM -0500, Tom Lane wrote:
Indeed, and if you've got examples where it's that far off, you should
report them.
Yeah, the trick is to get it to a digestable test case. The basic
scenario (there are more tables & columns in the actual case) is a set
of tables part
On Thu, 2007-12-06 at 08:50 +, Dave Page wrote:
> EnterpriseDB Postgres is essentially a packaging and bundling project in
> which the aim is to provide consistent and easy to use installers for
> Windows, Mac and Linux that allow users to get started with Postgres,
> Slony, PostGIS, pgAdmin,
hi i need to know all the database overhead sizes and block header sizes etc
etc as I have a very complex database to build and it needs to be speed
tuned beyond reckoning
I have gathered some relevant information form the documentation such as all
the data type sizes and the RM block informa
I wrote:
> Hmm. IIRC, there are smarts in there about whether a mergejoin can
> terminate early because of disparate ranges of the two join variables.
> Seems like it should be straightforward to fix it to also consider
> whether the time-to-return-first-row will be bloated because of
> disparate
Tom Lane wrote:
> Michael Stone <[EMAIL PROTECTED]> writes:
>> OTOH, the planner can really screw up queries on really large databases.
>> ... I've got some queries that the
>> planner thinks will return on the order of 10^30 rows for that sort of
>> reason. In practice, the query may return 10^
Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
>
>> Also shown below it seems that if I use "OFFSET 0" as a "hint"
>> I can force a much (10x) better plan. I wonder if there's room for
>> a pgfoundry project for a patch set that lets us use more hints
>> than OFFSET 0.
>>
> There's someth
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There's something fishy about this --- given that that plan has a lower
>> cost estimate, it should've picked it without any artificial
>> constraints.
> I think the reason it's not picking it was discussed back in this thread
> too.
> htt
Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> ...given that that plan has a lower cost estimate, it
>>> should've picked it without any artificialconstraints.
>
>>I think the reason it's not picking it was discussed back...
>> http://archives.postgresql.org/pgsql-
16 matches
Mail list logo
