Tom Lane wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
I am considering the possibility of rebuilding the server with
NAMEDATALEN equal to 256. I have seen an interesting thread [1] about
the performance impact of raising NAMEDATALEN, but it did not seem
conclusive.
More to the point
usage?
[1] http://archives.postgresql.org/pgsql-hackers/2002-04/msg01253.php
--
*
Ing. Alessandro Baretta
Studio Baretta
http://studio.baretta.com/
Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting
August Zajonc wrote:
Alessandro Baretta wrote:
Alessandro,
I've very much enjoyed reading your thoughts and the problem your facing
and everyone's responses.
Thank you for your interest, Agust.
Since you control the middle layer, could you not use a cookie to keep a
cursor open
[EMAIL PROTECTED] wrote:
On Tue, Jan 17, 2006 at 08:56:00PM +0100, Alessandro Baretta wrote:
I understand most of these issues, and expected this kind of reply. Please,
allow me to insist that we reason on this problem and try to find a
solution. My reason for doing so is that the future
Josh Berkus wrote:
People:
To follow up further, what Alessandro is talking about is known as a
keyset cursor. Sybase and SQL Server used to support them; I beleive
that they were strictly read-only and had weird issues with record
visibility.
I would like to thank everyone for sharing
[EMAIL PROTECTED] wrote:
On Wed, Jan 18, 2006 at 09:57:50AM +0100, Alessandro Baretta wrote:
I there is to be a change to PostgreSQL to optimize for this case, I
suggest it involve the caching of query plans, executor plans, query
results (materialized views?), LIMIT and OFFSET. If we had all
Tom Lane wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
I am aware that what I am dreaming of is already available through
cursors, but in a web application, cursors are bad boys, and should be
avoided. What I would like to be able to do is to plan a query and run
the plan to retreive
Craig A. James wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
I think you're trying to do something at the wrong layer of your
architecture. This task normally goes in your middleware layer, not
your database layer.
I am developing my applications in Objective Caml, and I have
I am aware that what I am dreaming of is already available through cursors, but
in a web application, cursors are bad boys, and should be avoided. What I would
like to be able to do is to plan a query and run the plan to retreive a limited
number of rows as well as the executor's state. This
Ottó Havasvölgyi wrote:
Hi all,
Is PostgreSQL able to throw unnecessary joins?
For example I have two tables, and I join then with their primary keys,
say type of bigint . In this case if I don't reference to one of the
tables anywhere except the join condition, then the join can be
Tom Lane wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
I have no clue as to how or why the statistics were wrong
yesterday--as I vacuum-analyzed continuously out of lack of any better
idea--and I was stupid enough to re-timestamp everything before
selecting from pg_stats.
Too bad. I
Hello gentlemen,
Although this is my first post on the list, I am a fairly experienced PostgreSQL
programmer. I am writing an ERP application suite using PostgreSQL as the
preferred DBMS. Let me state that the SQL DDL is automatically generated by a
CASE tool from an ER model. The generated
Matteo Beccati wrote:
Hi Alessandro,
Nested Loop (cost=0.00..1017.15 rows=1 width=1146) (actual
time=258.648..258.648 rows=0 loops=1)
- Seq Scan on ubicazione (cost=0.00..1011.45 rows=1 width=536)
(actual time=0.065..51.617 rows=12036 loops=1)
Filter: ((id_ente = 'dmd'::text)
Tom Lane wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
Matteo Beccati wrote:
Are you sure that you recentrly ANALYZED the table ubicazione? If so,
try to increase statistics for the id_ente column.
No, this is not the problem. I increased the amount of statistics with ALTER
TABLE
Tom Lane wrote:
Alessandro Baretta [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm curious to see how many rows the planner thinks this will produce,
and whether it will use the index or not.
dmd-freerp-1-alex=# EXPLAIN ANALYZE SELECT * FROM articolo WHERE
articolo.xdbs_modified '2006-01-08
15 matches
Mail list logo
