Re: Table has 22 million records, but backup doesn't see them

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: Radcon Entec <radconentec(at)yahoo(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Table has 22 million records, but backup doesn't see them
Date: 2009-04-08 19:15:05
Message-ID: 49DCF7B9.50409@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Radcon Entec wrote:
> ------------------------------------------------------------------------
> *
> *
> You are, of course, correct. "select count(*) from only feedback"
> returns 0. I have never used (or even seen) PostgreSQL rules before.
>
> When I run the query "select * from feedback where charge = 23017", I
> get 538 records. Adding the word "only" gives me zero records, as
> expected, and querying the feedback_active table gets me my 538
> records. But the feedback table only has the INSERT rules you quoted
> above. I clicked on the feedback table's Rules leaf and selected "New
> Rule", and saw that I can create SELECT, INSERT, UPDATE and DELETE
> rules. But even though I don't have a SELECT rule explicitly defined,
> PostgreSQL appears to be smart enough to retrieve data from the
> correct actual table when I think I'm selecting from the feedback
> table. Is that standard behavior?
>
> Of course, my next step will be to read the documentation.
>
You won't find the cause of your surprise reading up on rules. Read up
on inheritance, instead. It can do a lot, but a typical simple use is
table-partitioning as appears to be the case in your situation.

You start with the main (parent) table, say "events" then create a bunch
of child tables that inherit events, say events_jan, events_feb,
events_mar...

You never put actual data in "events" but create a rule or trigger that
looks at the month information and puts January events in events_jan,
February in events_feb and so on.

Select * from events is more-or-less equivalent to:
select * from events_jan union
select * from events_feb union...

Inheritance goes far beyond the simple case shown above. There's a lot
of nifty stuff you can do and a number of things that can bite you. But,
as you say, that's where the documentation comes in.

Cheers,
Steve

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ian Mayo 2009-04-08 19:30:28 Re: Are there performance advantages in storing bulky field in separate table?
Previous Message Robert Treat 2009-04-08 19:13:27 Re: Are there performance advantages in storing bulky field in separate table?