Hi everyone.
I have created a simplified example of a real case, to show you what I'm tryng to do. I have
a table, like this:
CREATE TABLE sales (
saleId SERIAL,
clientId INTEGER,
branchId INTEGER,
productId INTEGER,
employeeId INTEGER,
saleDate DATE,
price NUMERIC(12, 2)
what you say is that the index is not effective because of its size, but it would still be used *if* the conditions are right... In this case, I care about performance, not space.
But what you say about the index not being good because 100% of rows match the condition confirms what I suspecte
wouldn't also increasing shared_buffers to 64 or 128 MB be a good performance improvement? This way, pages belonging to heavily used indexes would be already cached by the database itself.
Please, correct me if I'm wrong.
On Mon, 2003-07-28 at 01:14, Josh Berkus wrote:
Daniel,
> > I just wo
But I think it's still a good option.
For example, in servers where there are other applications running (a web server, for example) that are constantly accesing the disk and replacing cached postgresql pages in the kernel, having shared buffers could reduce this efect and assure the precense
Wouldn't it be the most portable solution to work with a domain?
CREATE DOMAIN BIG_NUMBER AS BIGINT;
If I use BIG_NUMBER everywhere I need it in my database, porting it to other database products should be easy... any SQL 92 compliant dbms should support domains.
On Sun, 2003-09-28 at 00:06,
try this:
EXPLAIN [ANALYZE] SELECT a FROM table1 WHERE a IS NULL OR a>2;
SET enable_seqscan TO off;
EXPLAIN [ANALYZE] SELECT a FROM table1 WHERE a IS NULL OR a>2;
and compare the costs and times of both executions. This will tell you why postgresql is not using an index.
For example, if you
About a year ago I programmed a php/firebird application, and I've never had a problem with firebird. It's a small database (a few megabytes), but it just works day after day.
I've seen firebird has updatable views, they seem to work very well.
I have the feeling that It's not as flexible as
